ทำไมการสเตก ETH แบบ Native ถึงต้องรอคิวราว 32 วัน

หากคุณเพิ่งเข้าร่วม "Ethereum native staking" ด้วยตัวเอง คุณอาจเจอเหตุการณ์คุ้นตา: ฝาก ETH สำเร็จ ธุรกรรมบนเชนผ่านเรียบร้อย แต่สถานะของตัวตรวจสอบ (validator) ยังติดอยู่ที่ "queueing" และยังไม่เริ่มทำงานจริง โดยคิวนี้อาจยาวเกินหนึ่งเดือน ข้อมูล ณ วันที่ 16 กันยายน มี ETH มากกว่า 1.8 ล้าน ETH รอเข้าสู่ชุดตัวตรวจสอบ (validator set) คาดเวลารอราว 32 วัน ขณะที่เดือนกรกฎาคมปีนี้เคยพุ่งเกิน 43 วัน และช่วงคิวหนาแน่นสุดในเดือนมีนาคม มีราว 3.4 ล้าน ETH รออยู่หน้าประตู เวลารอเกือบ 60 วัน พูดว่า "รอเป็นเดือน" จึงไม่ใช่คำพูดเกินจริง คำถามคือ Ethereum สร้างสล็อตใหม่เฉลี่ยทุก 12 วินาที ธุรกรรมปกติยืนยันไว ทำไมการสเตกที่มีมูลค่านับพันล้านดอลลาร์ต้องรอเป็นสัปดาห์ ๆ และระหว่างรอมีรายได้ไหม ทำไมเข้าใช้เวลานาน แต่ถอนออกบางช่วงกลับใช้เวลาแค่ไม่กี่นาที คำตอบอยู่ที่กลไกสำคัญที่คนมักมองข้าม: "Validator Queue" 1) ตัวเลข "32 วัน" มาจากไหน ความเข้าใจผิดที่พบบ่อยคือ Ethereum บังคับล็อก ETH ใหม่ 40 วันก่อนเริ่มทำงาน จริง ๆ แล้วเวลาหนึ่งเดือนเป็นผลลัพธ์ที่เปลี่ยนแปลงตามคิว ณ ตอนนั้น หลักคิดง่าย ๆ คือ: ปริมาณ ETH ที่รออยู่ในคิว ÷ ปริมาณ ETH ที่โปรโตคอลอนุญาตให้เปิดใช้งานได้ต่อวัน = เวลารอโดยประมาณ PoS ของ Ethereum ไม่เปิดให้ตัวตรวจสอบใหม่เข้าพร้อมกันทั้งหมด แต่ใช้กลไก "churn limit" เพื่อจำกัดจำนวนยอดสเตกที่สามารถเข้าร่วม validator set ได้ในแต่ละ epoch - 1 epoch มี 32 สล็อต - 1 สล็อตใช้เวลาราว 12 วินาที - 1 epoch จึงยาวประมาณ 6.4 นาที - ต่อวันมีประมาณ 225 epoch หลัง Pectra/Electra การคำนวณเพดานอิง "ยอดคงเหลือ ETH" มากขึ้น ไม่ได้ดูจำนวน validator อย่างเดียว ปัจจุบันเพดานเปิดใช้งานสเตกใหม่อยู่ที่ 256 ETH ต่อ epoch ถ้าคิดเป็น validator มาตรฐาน 32 ETH เท่ากับอนุมัติได้สูงสุด 8 validator ทุก 6.4 นาที แปลงเป็นต่อวัน: 256 ETH × 225 ≈ 57,600 ETH/วัน ถ้ามี ETH รอเข้าระบบราว 1.83 ล้าน ETH จะได้: 1.83 ล้าน ÷ 57,600 ≈ 32 วัน นี่คือที่มาของวลี "รอเป็นเดือน" และตัวเลขนี้เปลี่ยนได้ทุกวัน ถ้าปริมาณ ETH ที่เข้าคิวน้อยกว่า 57,600 ETH/วัน แบ็กล็อกจะค่อย ๆ ลด เวลารออาจจาก 40 วันลงเหลือ 30 วัน หรือ 20 วัน แต่ถ้าเข้าคิวมากกว่านี้ คิวจะไม่สั้นลงและอาจยืดยาวขึ้น กรณีเดือนมีนาคมที่มี 3.4 ล้าน ETH รอเกือบ 60 วันคือภาพสุดโต่งของสถานการณ์นี้ ประเด็นสำคัญคือ "คิวสเตก" ไม่ได้เกี่ยวกับความแออัดของธุรกรรม (execution layer) โดยตรง ต่อให้ค่าแก๊สต่ำและบล็อกสเปซเหลือ ก็ไม่ได้แปลว่า validator จะเข้าได้ทันที เพราะคอขวดอยู่ที่ "ข้อจำกัดอัตราการเข้า" ที่โปรโตคอลตั้งใจวางไว้ 2) ทำไมไม่เพิ่มเพดานให้เข้าได้ทีเดียว เมื่อการรอนานทำให้เงินไม่สร้างผลตอบแทน วิธีที่ดูตรงไปตรงมาคือเพิ่มเพดาน 256 ETH ต่อ epoch แต่ validator ไม่ใช่บัญชีทั่วไป โอน ETH เสร็จแล้วแทบไม่เพิ่มภาระระยะยาวให้เครือข่าย แต่เมื่อ validator ถูกเปิดใช้งาน จะกลายเป็นผู้เล่นระยะยาวในระบบฉันทามติ ต้องทำ attestation ถูกจัดเข้าคณะกรรมการ (committee) และร่วมสร้างฉันทามติ ปัจจุบัน Ethereum มี validator ที่ active มากกว่า 900,000 ราย และมี ETH สเตกรวมมากกว่า 42 ล้าน ETH ทุก validator ใหม่เพิ่มความซับซ้อนให้ระบบนี้ นี่จึงเป็นเหตุผลที่ Ethereum พยายามควบคุมอัตราการเปลี่ยนแปลงของ validator set มาโดยตลอด EIP-7514 ที่เสนอในปี 2023 กำหนดเพดานอัตราการเปิดใช้งาน validator โดยเจตนา เหตุผลไม่ใช่ "คนสเตกเยอะเป็นเรื่องแย่" แต่เป็นความกังวลว่าการเติบโตแบบไร้ขีดจำกัดจะเพิ่มขนาดสถานะในชั้นฉันทามติ เพิ่มต้นทุนการจัดการ validator และกดดันการสื่อสาร/ประมวลผลของเครือข่าย หลังอัปเกรด Pectra Ethereum ยังเปิดให้เพิ่ม effective balance ของ validator เดียวได้สูงสุดถึง 2048 ETH ส่วนหนึ่งเพื่อช่วยลดความจำเป็นที่รายใหญ่ต้องแตกก้อนเป็น validator 32 ETH จำนวนมาก ลดภาระจากจำนวน validator ที่โตไม่หยุด เหนือสิ่งอื่นใด churn limit ยังทำหน้าที่เชิงความมั่นคง: กันไม่ให้กลุ่มผู้ค้ำประกันความปลอดภัยของเครือข่ายเปลี่ยนแปลงรวดเร็วเกินไปในช่วงเวลาสั้น ๆ ความปลอดภัยของ PoS พึ่งพา active validator set หากเงินก้อนใหญ่เข้า-ออกได้ทันที ฐานการตัดสินว่าใครมีสิทธิร่วมฉันทามติและระดับหลักประกันทางเศรษฐกิจจะเปลี่ยนเร็วเกินควบคุม Ethereum จึงตั้งเพดานความเร็วของการเปลี่ยนแปลงนี้ไว้โดยมนุษย์ ด้วยเหตุนี้ "การต่อคิว" ไม่ใช่บั๊กที่ต้องแก้ แต่เป็นคอสะพานที่ตั้งใจทำ จากมุมผู้ใช้ มันลดประสิทธิภาพการใช้ทุน แต่จากมุมโปรโตคอล มันคือ "เนินชะลอ" ที่สะท้อนว่า Ethereum ยอมให้มี ETH นับล้านรอเป็นสัปดาห์ ดีกว่าให้ validator set ขยายหรือหดแบบฉับพลันภายในไม่กี่วัน แม้แผนในอนาคตก็ยังสะท้อนแนวคิดนี้ โดยแนวทางที่มีการพูดถึงคือการรวม EIP-8061 ใน Glamsterdam เพื่อเพิ่มขีดความสามารถฝั่งการออก (exit) และการรวม validator (merge) เพื่อลดคอขวดการถอน แต่ยังคงเพดานการเปิดใช้งานฝั่งเข้าไว้ที่ 256 ETH/epoch กล่าวคือ ยืดหยุ่นให้ "ออก" มากขึ้น แต่ยังไม่เปิดประตู "เข้า" แบบเต็มที่ 3) ระหว่างรอคิวมีผลตอบแทนไหม และทำไมออกถึงดูเร็ว หากฝาก ETH แล้ว ช่วงรอหนึ่งเดือนนับว่าได้สเตกและได้ผลตอบแทนหรือไม่ ในมุมของรางวัลจากโปรโตคอล คำตอบคือ "ยัง" ผลตอบแทนเริ่มนับเมื่อ validator เข้าสถานะ Active จริงเท่านั้น คือเริ่มทำ attestation ร่วมเสนอ/ยืนยันบล็อก และรับรางวัลตามโปรโตคอล ก่อนหน้านั้นหากยังอยู่สถานะ Pending ต่อให้ธุรกรรมฝากผ่านแล้ว ก็ยังไม่เกิดรางวัลสเตกตามปกติ โดย Ethereum.org ถือว่าเริ่มทำงานและเริ่มสร้างรางวัลเมื่อสถานะเป็น "Active" นี่ทำให้คิวกระทบผู้ใช้ชัดเจนขึ้น หาก APR เฉลี่ยทั้งเครือข่ายอยู่ราว 2.6% ตัวอย่าง validator 32 ETH ที่ต้องรอ 40 วัน จะเสียโอกาสรางวัลจากโปรโตคอลราว 0.09 ETH ต่อราย บุคคลทั่วไปอาจมองว่าไม่มาก แต่สำหรับสถาบันที่ต้องนำ ETH หลักหมื่นหรือหลักแสนไปใช้งาน ต้นทุนเงินว่าง 40 วันจะขยายตัวเร็วมาก จึงไม่น่าแปลกที่ช่วงหลังคิวสเตกของ Ethereum ถูกจับตาจากสถาบันและบริษัทที่บริหารคลัง ETH มากขึ้น ในอดีตผู้คนมักเปรียบเทียบวิธีสเตกจากส่วนต่าง APR หรือค่าธรรมเนียมเล็กน้อย แต่เมื่อ "เวลารอคิว" ยาวเป็นเดือน คำถามว่า "เริ่มสร้างผลตอบแทนจริงเมื่อไร" กลายเป็นตัวแปรด้านประสิทธิภาพทุนไปด้วย แล้วทำไมฝั่งถอนออกจึงมักเห็นคิวแค่ไม่กี่นาทีถึงไม่กี่ชั่วโมง หมายความว่า Ethereum ให้คนออกเร็วแต่เข้าช้าหรือไม่ ความจริงคือทั้งฝั่งเข้าและฝั่งออกต่างมี churn limit และถูกจำกัดอัตราโดยโปรโตคอลเหมือนกัน ความยาวคิวขึ้นกับจำนวนคนรอ ปัจจุบันมีมากกว่า 2 ล้าน ETH รอเข้า แต่ฝั่งออกมีคนน้อย จึงเหมือนถนนที่ขาเข้ารถติดยาวหลายสิบกิโลเมตร ส่วนขาออกโล่ง อีกจุดที่มักถูกเข้าใจผิดคือ "คิวออกสั้น" ไม่ได้แปลว่าเงินจะกลับเข้ากระเป๋าภายในไม่กี่นาที หลัง validator ออกสำเร็จ ยังต้องรอระยะเวลาคงที่ 256 epoch หรือประมาณ 27 ชั่วโมง จึงเข้าสถานะถอนได้ (withdrawable) จากนั้นยังต้องรอระบบ "Withdrawal Sweep" ของ Ethereum โอนเงินไปยังที่อยู่ถอน ซึ่งอาจเพิ่มเวลาได้อีกหลายวัน สำหรับผู้ใช้ทั่วไป เรื่องนี้ยังเชื่อมไปถึงความต่างระหว่างผลิตภัณฑ์สเตก หากคุณรัน validator เอง หรือสร้าง validator แบบอิสระผ่านบริการสเตกแบบไม่ฝากทรัพย์ (non-custodial) อย่าง imToken กระบวนการพื้นฐานยังต้องให้ validator เข้า validator set อย่างเป็นทางการ จึงต้องผ่านคิวของโปรโตคอลเหมือนเดิม ในกรณี non-custodial staking ของ imToken ผู้ใช้ถือกุญแจถอน (withdrawal key) ขณะที่ผู้ให้บริการโหนดเป็นผู้ดำเนินการ validator เมื่อหน้าแอปขึ้น "Queuing" แปลว่า validator รอการอนุมัติจาก Ethereum และจะเริ่มสร้างรางวัลโปรโตคอลเมื่อสถานะเปลี่ยนเป็น "Active" ขณะที่พูลสเตกแบบลิควิดบางรายมี validator ที่ active อยู่จำนวนมากและมีโทเคนลิควิด (LST) จึงสามารถ "ซ่อน" ช่วงรอไร้ผลตอบแทนนี้ในระดับผลิตภัณฑ์ ผู้ใช้อาจไม่รู้สึกถึงการรอหลายสิบวันโดยตรง แต่แลกกับขอบเขตความเชื่อใจชุดใหม่ ทั้งความเสี่ยงสัญญาอัจฉริยะ สภาพคล่อง LST ธรรมาภิบาลโปรโตคอล และความเสี่ยงจากการสวอปสินทรัพย์ ซึ่งมักถูกบดบังเมื่อคนโฟกัสแค่ APR เพราะต้นทุนที่แท้จริงของการสเตกไม่ใช่แค่ค่าธรรมเนียมและผลตอบแทน สรุป ภายนอกอาจดูเหมือนดีไซน์ที่ไม่มีประสิทธิภาพ เมื่อ Ethereum ปล่อยให้ ETH นับล้านต้องยืนรอหน้าประตูกว่าเดือน แต่ถ้ามองทั้งเครือข่าย ภาพจะชัดขึ้น: ธุรกรรมทั่วไปต้องการความเร็ว ส่วน validator คือผู้รักษาฉันทามติของ Ethereum ในวินาทีถัดไป เรื่องแรกเร่งให้เร็วได้ไม่สิ้นสุด เรื่องหลังต้องมีความยับยั้ง คิวที่ยาวจึงสะท้อนว่า "รั้วความปลอดภัย" ที่เคยมองไม่เห็น กลายเป็นสิ่งที่ผู้ใช้เห็นชัดเมื่อความต้องการสเตกสูงกว่าอัตรารับเข้าอย่างมากของโปรโตคอล ยิ่งคิวยาว ก็ยิ่งบ่งชี้ว่าในช่วงนี้ความต้องการเข้าร่วม validator set ยังวิ่งเร็วกว่าความเร็วที่ Ethereum อนุญาตให้เข้ามา และไม่ว่าคนจะรออยู่ข้างนอกมากแค่ไหน Ethereum ก็จะเปิดประตูตามจังหวะของตัวเอง ทีละ epoch