การเปลี่ยน Ethereum เป็น PoS "The Merge" จะส่งผลต่อ Application Layer อย่างไร?
แหล่งที่มา:
แหล่งที่มา:บล็อกอย่างเป็นทางการของ Ethereum

การเปลี่ยนแปลงของเครือข่าย Ethereum ไปสู่การพิสูจน์การถือหุ้น (The Merge) ใกล้เข้ามาแล้ว: ขณะนี้เครือข่ายนักพัฒนากำลังถูกสร้างขึ้น ข้อมูลจำเพาะกำลังได้รับการสรุป และการเตรียมการสำหรับการเข้าถึงชุมชนได้เริ่มต้นขึ้นอย่างจริงจัง The Merge ได้รับการออกแบบมาเพื่อการเปลี่ยนผ่านโดยมีผลกระทบต่อผู้ใช้ปลายทาง วิธีการทำงานของ smart contracts และ dapps น้อยที่สุด ที่กล่าวว่ามีการเปลี่ยนแปลงเล็กน้อยที่ควรค่าแก่การเน้นไปพร้อมกัน ก่อนที่เราจะลงลึกในการเปลี่ยนแปลง ต่อไปนี้เป็นลิงก์บางส่วนที่ให้ข้อมูลเชิงลึกเกี่ยวกับสถาปัตยกรรมโดยรวมของ The Merge:
วิวัฒนาการของแผนงาน
สถาปัตยกรรมไคลเอนต์ผสาน
ส่วนที่เหลือของบทความนี้จะถือว่าผู้อ่านคุ้นเคยกับข้อความข้างต้นแล้ว สำหรับผู้ที่ต้องการเจาะลึกข้อมูลจำเพาะทั้งหมดของ The Merge สามารถดูได้ที่ด้านล่าง:
ชั้นฉันทามติ
ชั้นฉันทามติ
เครื่องยนต์ API
1
โครงสร้างบล็อก

หลังจากการควบรวม Ethereum แล้ว Proof of Work (PoW) จะไม่มีอยู่ในเครือข่ายอีกต่อไป แต่ส่วน PoW เดิมจะกลายเป็นส่วนสำคัญของบล็อกที่สร้างขึ้นบน Beacon Chain จากนั้นคุณสามารถคิดว่า beacon chain เป็นชั้นฉันทามติ PoS ใหม่สำหรับ Ethereum แทนที่ชั้นฉันทามติ PoW ก่อนหน้านี้ บล็อก Beacon Chain จะมี ExecutionPayloads ซึ่งเทียบเท่ากับบล็อกในห่วงโซ่ PoW ปัจจุบัน แผนภาพด้านล่างแสดงความสัมพันธ์นี้:
สำหรับผู้ใช้ปลายทางและนักพัฒนาแอปพลิเคชัน ExecutionPayloads เหล่านี้เป็นที่ที่โต้ตอบกับ Ethereum ธุรกรรมในเลเยอร์นี้จะยังคงดำเนินการโดยไคลเอนต์เลเยอร์การดำเนินการ (Besu, Erigon, Geth, Nethermind เป็นต้น) โชคดีที่ The Merge นำเสนอการเปลี่ยนแปลงการแตกหักเพียงเล็กน้อยเนื่องจากความเสถียรของชั้นการดำเนินการ
2
ฟิลด์การขุดและบล็อก Ommer
หลังจากการควบรวม ฟิลด์ต่างๆ ที่ก่อนหน้านี้รวมอยู่ในส่วนหัวของบล็อก PoW จะไม่ถูกใช้งานอีกต่อไป เนื่องจากฟิลด์เหล่านั้นไม่เกี่ยวข้องกับ PoS เพื่อลดการหยุดชะงักของเครื่องมือและโครงสร้างพื้นฐาน ฟิลด์เหล่านี้จะถูกตั้งค่าเป็น 0 หรือเทียบเท่ากับโครงสร้างข้อมูล แทนที่จะลบออกจากโครงสร้างข้อมูลทั้งหมด คุณสามารถค้นหาการเปลี่ยนแปลงทั้งหมดเพื่อบล็อกฟิลด์ได้ใน EIP-3675

เนื่องจาก PoS ไม่สร้าง ommers (หรือเรียกว่าบล็อกลุง) ตามธรรมชาติเหมือน PoW รายการเหล่านี้ในแต่ละบล็อกลุง (ommers) จะว่างเปล่า และแฮชของรายการนี้ (ommersHash) จะกลายเป็นแฮชว่างของรายการแฮชที่เข้ารหัส RLP นอกจากนี้ เนื่องจาก PoW มีความยากและ nonce ด้วย จึงจะถูกตั้งค่าเป็น 0 หลังจากนั้นให้ค่าขนาดเป็นไบต์
อีกฟิลด์ที่เกี่ยวข้องกับการขุดคือ mixHash จะไม่ถูกตั้งค่าเป็น 0 แต่จะมีค่า RANDAO ของสายบีคอน เพิ่มเติมเกี่ยวกับเรื่องนี้ด้านล่าง
3
BLOCKHASH & การเปลี่ยนแปลง opcode ที่ยากลำบาก
หลังจากผสานรวมแล้ว opcode ของ BLOCKHASH จะยังคงใช้งานได้ แต่การสุ่มหลอกที่มาจาก opcode นี้จะอ่อนแอลงมาก เนื่องจากไม่ได้ถูกปลอมแปลงโดยขั้นตอนการแฮชของ PoW อีกต่อไป
ในทำนองเดียวกัน opcode ที่ยาก (0x44) จะได้รับการอัปเดตและเปลี่ยนชื่อเป็น RANDOM เมื่อรวมเข้าด้วยกันแล้ว จะส่งคืนเอาต์พุตของบีคอนแบบสุ่มที่จัดเตรียมโดยบีคอนเชน ดังนั้นเมื่อเปรียบเทียบกับ BLOCKHASH แล้ว opcode นี้จะเป็นแหล่งสุ่มที่แข็งแกร่งกว่าสำหรับนักพัฒนาแอปพลิเคชันที่จะใช้ แม้ว่าจะยังมีอคติอยู่ก็ตาม
ค่าที่เปิดเผยโดย RANDOM จะถูกจัดเก็บไว้ใน ExecutionPayload ซึ่งเก็บค่า mixHash ที่เกี่ยวข้องกับการคำนวณ PoW ช่อง mixHash ของ Payload จะถูกเปลี่ยนชื่อเป็นแบบสุ่ม
นี่คือภาพประกอบของวิธีการทำงานของ opcodes DIFFICULTY & RANDOM ก่อนและหลังการรวม:

ก่อนการผสาน เราจะเห็นว่า opcode 0x44 ส่งคืนฟิลด์ความยากในส่วนหัวของบล็อก หลังจากการผสาน opcode เปลี่ยนชื่อเป็น RANDOM ชี้ไปที่ฟิลด์ส่วนหัวของบล็อกที่ก่อนหน้านี้มี mixHash และตอนนี้เก็บค่าแบบสุ่มจากสถานะลูกโซ่บีคอน
การเปลี่ยนแปลงนี้ซึ่งจัดทำอย่างเป็นทางการใน EIP-4399 ยังให้แอปพลิเคชันแบบออนไลน์พร้อมวิธีการประเมินว่าเกิดการผสานหรือไม่ ตามการแนะนำของ EIP นี้:
นอกจากนี้ การเปลี่ยนแปลงที่เสนอโดย EIP นี้ทำให้สัญญาอัจฉริยะสามารถระบุได้ว่ามีการอัปเกรดเป็น PoS หรือไม่ ซึ่งสามารถทำได้โดยการวิเคราะห์ค่าส่งคืนของรหัส DIFFICULTY หากค่ามากกว่า 2**64 แสดงว่าธุรกรรมกำลังดำเนินการในบล็อก PoS
4
บล็อกเวลา
การควบรวมกิจการจะส่งผลต่อเวลาบล็อกเฉลี่ยของ Ethereum ในปัจจุบัน ภายใต้ PoW บล็อกจะสร้างทุกๆ 13 วินาทีโดยเฉลี่ย และช่วงเวลาของบล็อกที่เกิดขึ้นจริงมีความแตกต่างอย่างมาก ภายใต้ Proof-of-stake ช่วงเวลาการบล็อกจะเท่ากับ 12 วินาทีพอดี เว้นแต่ว่าสล็อตจะพลาดไปเนื่องจากตัวตรวจสอบความถูกต้องออฟไลน์หรือเพราะพวกเขาไม่ได้คอมมิตการบล็อกทันเวลา ในทางปฏิบัติ สิ่งนี้เกิดขึ้นกับสล็อต<1%。
ซึ่งแปลเป็น ~1 วินาทีในการบล็อกเวลาเฉลี่ยบนเครือข่าย สัญญาอัจฉริยะที่ถือว่าเวลาบล็อกเฉลี่ยที่แน่นอนในการคำนวณจำเป็นต้องคำนึงถึงสิ่งนี้ด้วย
5
หัวที่ปลอดภัยและบล็อกสุดท้าย
ภายใต้ PoW การปรับโครงสร้างบล็อกสามารถทำได้เสมอ โดยทั่วไปแล้ว แอปพลิเคชันจะรอให้ขุดบล็อกสองสามช่วงบนหัวที่ปลอดภัยใหม่ก่อนที่จะพิจารณาว่าไม่น่าจะถูกลบออกจากห่วงโซ่มาตรฐาน หรือได้รับการ "ยืนยัน" แล้ว หลังจากการรวมเข้าด้วยกัน เรามีความคิดของบล็อกหัวสุดท้ายและปลอดภัย บล็อกเหล่านี้สามารถใช้งานได้อย่างน่าเชื่อถือมากกว่าบล็อก PoW ที่ "ยืนยัน" แต่ต้องมีการเปลี่ยนแปลงความเข้าใจเพื่อใช้อย่างถูกต้อง
บล็อกสุดท้ายคือบล็อกที่ได้รับการยอมรับจากผู้ตรวจสอบความถูกต้องมากกว่า 2/3 ในการสร้างบล็อกที่ขัดแย้งกัน ผู้โจมตีจะต้องเผาอย่างน้อย 1/3 ของ ETH ที่วางเดิมพันทั้งหมด ซึ่งในขณะที่เขียนหมายความว่า ETH มากกว่า 10,000 ล้านดอลลาร์ (หรือ >2.5 ล้าน)
หัวที่ปลอดภัยคือบล็อกที่เราต้องการรวมไว้ในเชนบัญญัติภายใต้เงื่อนไขเครือข่ายปกติ สมมติว่าเวลาแฝงของเครือข่ายน้อยกว่า 4 วินาที โปรแกรมตรวจสอบส่วนใหญ่จะซื่อสัตย์ และไม่มีการโจมตีกฎการเลือกทางแยก ดังนั้นหัวหน้าที่ปลอดภัยจะไม่กลายเป็นบล็อกกำพร้า มีการนำเสนอรายละเอียดวิธีคำนวณหัวที่ปลอดภัยในสถานการณ์ต่างๆ ที่นี่ นอกจากนี้ สมมติฐานและการรับประกันของหัวหน้าที่ปลอดภัยจะได้รับการกำหนดและวิเคราะห์อย่างเป็นทางการในเอกสารฉบับต่อไป
หลังจากการผสาน API ของเลเยอร์การดำเนินการ (เช่น JSON RPC) จะส่งคืนค่าหัวที่ปลอดภัยโดยค่าเริ่มต้นเมื่อระบบถามถึงบล็อกล่าสุด ภายใต้เงื่อนไขของเครือข่ายปกติ หัวเซฟและส่วนบนจริงของโซ่จะเท่ากัน (ส่วนหัวและส่วนท้ายที่ปลอดภัยเพียงไม่กี่วินาที) หัวที่ปลอดภัยมีโอกาสน้อยที่จะได้รับการจัดระเบียบใหม่เมื่อเทียบกับบล็อกล่าสุดของ PoW ในปัจจุบัน เพื่อที่จะเปิดเผยส่วนปลายที่แท้จริงของเชน PoW แฟล็กที่ไม่ปลอดภัยจะถูกเพิ่มใน JSON RPC
บล็อกที่สรุปแล้วจะถูกเปิดเผยผ่าน JSON RPC ผ่านแฟล็กที่สรุปแล้วใหม่ สิ่งเหล่านี้สามารถใช้เป็นทางเลือกที่ดีกว่าในการพิสูจน์ PoW ตารางด้านล่างสรุปสิ่งนี้:
ขั้นตอนต่อไป

6
ขั้นตอนต่อไป
บทความนี้มาจาก Tao of Yuan Universe ทำซ้ำโดยได้รับอนุญาต
บทความนี้มาจาก Tao of Yuan Universe ทำซ้ำโดยได้รับอนุญาต


