The Merge การอัพเกรดครั้งใหญ่ของ Ethereum เสร็จสิ้นเรียบร้อย : The Merge คือการเปลี่ยนแปลงระบบจาก Proof-of-Work ไปเป็น Proof-of-Stake ซึ่งระบบนี้จะทำให้ Consensus Mechanism ของ Ethereum นั้นประหยัดพลังงานมากขึ้น อีกทั้งยังทำให้ Supply ที่ผลิตออกมาต่อวันลดลงจาก 13,000 เหรียญไปเป็น 3000 เหรียญต่อวันอีกด้วย
BREAKING: Ethereum, $ETH successfully merges to proof-of-stake.
— Watcher.Guru (@WatcherGuru) September 15, 2022
Proof-of-Stake เป็นระบบที่ประหยัดพลังงานมากเมื่อเทียบกับ Proof of Work ที่ต้องอาศัยคอมพิวเตอร์ที่ต้องใช้ไฟในการทำงานตลอดเวลา ในขณะที่ Proof of Stake จะอาศัยคนที่ดูแลระบบโดยจะขึ้นอยู่กับจำนวนเหรียญที่ stake ไว้ ซึ่งหมายความว่า ใครที่มีจำนวนเหรียญ ETH มากกว่าก็มีสิทธิ์ในการยืนยันธุรกรรมบนเชนมากกว่า
[[ หลัง The Merge ]]
ระบบ Node ของ Ethereum จะใช้ 2 ชุด software คือ Consensus (ระบบฉันทามติ PoS) และ Execution (เหมือนก่อน The Merge) เพิ่มเติมคือมีระบบ Engine API เพิ่มเข้ามา ที่ใช้คุยกันระหว่าง Consensus layer และ Exection layer โดยทั้ง 2 ชุด software จะต้องอัพเดต version ให้รองรับเอาไว้ก่อน The Merge (ไม่งั้นจะคุยกับเครือข่ายไม่รู้เรื่อง)
[[ ระหว่าง The Merge ]]
สมมุติว่า Block ที่ N คือก่อน The Merge และ Block ที่ N+1 คือหลัง The Merge
ส่ิงที่เกิดขึ้นคือ ณ Block ที่ N ทุกอย่างยังเป็นปกติคือ Miners (เครื่องขุด) จะแข่งขันกันสร้าง Block และคนที่ชนะก็จะประกาศ Block ที่ N ออกมา ณ block นี้จะถึงค่า Terminal Total Difficulty (TTD) ที่กำหนดพอดี
– หลังจาก Block N ประกาศออกมา ทั้งเครือข่ายจะรับรู้ว่าถึงค่า TTD ที่กำหนดแล้ว และหยุดการทำงานของระบบ PoW ทั้งเครือข่าย เพื่อก้าวไปสู่ PoS ใน Block ถัดไป (N+1)
– ณ Block N+1 ระบบ PoS (consensus layer ใหม่) จะทำการคัดเลือกผู้สร้าง Block N+1 จาก Validators* ที่มีทั้งหมดในระบบ และผู้ที่ได้รับเลือกจะมีสถานะเป็น Proposer (ผู้เสนอ Block) ทำหน้าที่สร้าง Block (เรียงธุรกรรม ประมวลผล จัดเก็บชุดข้อมูล) และเสนอไปยังเครือข่าย หลังจากนั้นจะมี Attesters (พยาน) ลงความเห็นว่า Block ที่ Proposer เสนอมานั้นถูกต้องหรือไม่ และ Block N+2 และหลังจากนั้น ก็จะทำแบบนี้กันไปเรือย ๆ
* Validators เกิดจากผู้ที่ Stake (ฝาก) 32 ETH จะนับเป็น 1 validator ณ ตอนที่เขียนมีทั้งหมด 428,299 validators (~13,000,000 ETH)
* ใน 1 Block จะมี 1 Proposer และมี หลาย Attester ที่ถูกคัดเลือกผ่านระบบ PoS
* 1 Block ใน Execution layer จะเรียก Block ใน Consensus layer จะเรียก Slot (ที่จะมี Block ผูกอยู่ในนั้น) และ Block กับ Slot จะเป็นคนละเลขกัน
* Beacon chain ระบบทำงานมาเกือบ 2 ปีแล้ว (แต่ไม่มี Execution layer ก่อน The Merge)
แล้วไว้เจอกันหลัง The Merge นะครับ
ข้อมูลจากเพจ : Tot Nattapon
Transaction Types บน Ethereum มีอะไรบ้าง
#Devnote
Transaction Types บน Ethereum มีทั้งหมด 2 Format คือ
Legacy Transaction กับ Typed Transaction
–
1. Legacy Transaction
เป็น format ที่ถูกใช้ตั้งแต่แรก จนกระทั้งก่อนการเสนอ EIP-2718, ตัว Legacy นี้จะประกอบไปด้วย fields nonce, gasPrice, gasLimit, to, value, data, v, r และ s (ซึ่ง 3 ตัวหลังเป็นส่วนหนึ่งใน signed signature) โดยที่ fields เหล่านี้เราจะรู้จักกันในอีกชื่อว่า RLP
เราสามารถจำแนก Transaction Types แต่ละแบบได้โดยการดูที่ prefix 8-bit แรก ซึ่ง Legacy Transaction จะขึ้นต้นด้วย `0x0` เสมอ
–
2. Typed Transaction
เป็นนิยามใหม่ของการกำหนดมาตรฐานของ Transaction บน Ethereum โดยจะประกอบไปด้วย 2 ส่วน คือ TransactionType || TransactionPayload
– TransactionType คือ ส่วน prefix ที่จะบอกรูปแบบของการ encoding
– TransactionPayload คือ เนื้อของ Transaction ที่ถูก encoding มา
Typed Transaction ณ ปัจจุบันมีทั้งหมด 2 รูปแบบคือ AccessList และ DynamicFee
– Access List Type (EIP-2930, TransactionType: 0x1): มาตอน Berlin Fork ตัวมันเองมีประกอบด้วย fields ทั้งหมดที่ Legacy และเพิ่มเติมข้อมูลของ address หรือ storage keys ที่ต้องการเข้าถึงภายใน tx นี้ ข้อดีคือ จะทำให้การ execution/validation block ในบางจังหวะสามารถทำได้แบบ parallel (Idea เหมือน Sealevel ของ Solana)
(geak) แล้ว tx ที่เป็น types นี้จะมีค่า gas ที่ถูกลงนิดหน่อย (ถ้าทำถูกต้องตามมาตราฐาน) ให้ลองนึกภาพว่า ถ้ากรณีที่เราต้องการ access address/storage ของ smart contract ขึ้นมาหลายๆ ครั้ง ใน tx นั้น ปกติเราจะเสียค่าแก็สคงที่ทุกครั้งที่ execute opcode แต่การระบุ access list ฝั่ง evm จะมองว่าเข้าถึงได้ทันทีเพราะระบุว่าต้องการ access ไว้แล้ว (มันจะ pre-pay ค่า access ก่อน และตอน access จะจ่ายถูกลงมาก) กลับกันในกรณีที่ไม่มีการระบุว่าจะ access แต่ดันมีการ access จะจ่ายแพงขึ้นนิดหน่อย
– Dynamic Fee Type (EIP-1559, TransactionType: 0x2): มาตอน London Fork, ตัวมันเองมีประกอบด้วย fields ทั้งหมดที่ Legacy และ AccessList มี โดย Transaction ประเภทนี้จะไม่มีการระบุ GasPrice แต่จะมีการคิดค่า fee จาก 2 ส่วนคือ BaseFee + ProrityFee โดยที่ BaseFee คือค่า Gas พื้นฐานที่ต้องจ่ายขณะทำธุรกรรมอยู่แล้ว แต่ PriorityFee คือ tips เพิ่มเติมที่ผู้ทำธุรกรรมใส่เข้าไปเพิ่มเพื่อเป็นแรงจูงใจให้ miner เลือกธุรกรรมไป process และที่ถูกพูดถึงมากที่สุดคือ BaseFee ของ tx ประเภทนี้จะถูก burn ทิ้งในขณะที่ PriorityFee จะเป็น incentive ให้กับ miner
.
