บทวิเคราะห์เชิงลึกเส้นทางการรีสเตคของ EigenLayer: กับดักที่เคยเจอ, ความสำเร็จของ EigenDA, ล้วนเป็นการปูทางสู่ทิศทางใหม่ EigenCloud บทความนี้มาจาก Kydo, ผู้นำการเล่าเรื่องของ EigenCloud, โดย Saoirse, Foresight News เรียบเรียง, แปลและเขียน
(เกริ่นนำ: รายงานหมื่นคำ》เจาะลึกผู้นำรีสเตค EigenLayer)
(ข้อมูลพื้นหลัง: โปรโตคอลรีสเตค EigenLayer และผลิตภัณฑ์เรือธง EigenDA คืออะไร?)
เป็นระยะ ๆ เพื่อน ๆ มักจะส่งโพสต์ล้อเลียนรีสเตคมาให้ผม แต่ล้อเลียนเหล่านั้นกลับไม่โดนประเด็นเลยสักครั้ง ดังนั้นผมจึงตัดสินใจเขียน “บทบ่น” ที่มีแง่คิดสะท้อนด้วยตนเองขึ้นมา
คุณอาจคิดว่าผมใกล้ชิดกับเรื่องนี้เกินไปจนไม่อาจรักษาความเป็นกลาง หรืออาจจะหยิ่งเกินกว่าจะยอมรับว่า “เราคิดผิด” คุณอาจรู้สึกว่า แม้ทุกคนจะเห็นตรงกันว่า “รีสเตคล้มเหลว” ผมก็ยังจะเขียนบทความยาวเหยียดเพื่อแก้ต่าง ไม่ยอมเอ่ยคำว่า “ล้มเหลว” ออกมา
มุมมองเหล่านี้สมเหตุสมผล และหลายข้อก็มีน้ำหนัก
แต่บทความนี้แค่อยากนำเสนอข้อเท็จจริงอย่างตรงไปตรงมา: เกิดอะไรขึ้น, อะไรที่เป็นจริง, อะไรที่ไม่สำเร็จ, และบทเรียนที่เราได้เรียนรู้
ผมหวังว่าประสบการณ์ในบทความนี้จะเป็นสากล สามารถเป็นข้อมูลอ้างอิงสำหรับนักพัฒนาในระบบนิเวศอื่น ๆ ได้
หลังจากเชื่อมต่อ AVS หลัก ๆ ทั้งหมด (บริการตรวจสอบอิสระ) บน EigenLayer และออกแบบ EigenCloud มากว่าสองปี ผมอยากทบทวนอย่างตรงไปตรงมาว่า: เราผิดตรงไหน, ถูกตรงไหน, และจะเดินไปทางใดต่อ
รีสเตค (Restaking) คืออะไรกันแน่?
ทุกวันนี้ผมยังต้องอธิบายว่า “รีสเตคคืออะไร” ซึ่งนั่นแสดงว่า ตอนที่รีสเตคยังเป็นจุดสนใจของวงการ เราอธิบายมันได้ไม่ดีพอ นี่คือ “บทเรียนข้อที่ 0” — โฟกัสที่เนื้อหาหลักและถ่ายทอดซ้ำ ๆ
เป้าหมายของทีม Eigen คือ “พูดง่ายแต่ทำยาก”: ยกระดับความสามารถในการตรวจสอบของการคำนวณนอกบล็อกเชน เพื่อให้คนสามารถสร้างแอปพลิเคชันบนเชนได้อย่างปลอดภัยยิ่งขึ้น
AVS คือความพยายามแรกและชัดเจนของเรา
AVS (บริการตรวจสอบอิสระ) คือเครือข่าย Proof of Stake (PoS) กลุ่มหนึ่ง โดยมีโอเปอเรเตอร์แบบกระจายศูนย์ดำเนินงานภารกิจนอกบล็อกเชน พฤติกรรมของโอเปอเรเตอร์เหล่านี้จะถูกตรวจสอบ หากละเมิดกติกาจะถูกหักเงินที่สเตคไว้ และกลไก “ลงโทษ” นี้ต้องอาศัย “ทุนสเตค” เป็นหลักประกัน
นี่คือคุณค่าของรีสเตค: โดยไม่ต้องให้แต่ละ AVS สร้างระบบความปลอดภัยตั้งแต่ศูนย์ รีสเตคช่วยให้สามารถนำ ETH ที่สเตคไว้แล้วมาใช้ซ้ำ เพื่อค้ำประกัน AVS หลายระบบพร้อมกัน ซึ่งลดต้นทุนเงินทุนและเร่งการเติบโตของระบบนิเวศ
ดังนั้น กรอบแนวคิดของรีสเตคสามารถสรุปได้ดังนี้:
AVS: “เลเยอร์บริการ” คือฐานของระบบความปลอดภัย PoS แบบใหม่
รีสเตค: “เลเยอร์ทุน” ที่ใช้ทุนสเตคเดิมมาค้ำประกันความปลอดภัยของระบบเหล่านี้
ถึงวันนี้ ผมยังคิดว่าคอนเซปต์นี้ยอดเยี่ยม แต่ความเป็นจริงกลับไม่สวยงามอย่างในแผนผัง—หลายอย่างไม่เข้าเป้า
สิ่งที่ไม่เป็นไปตามคาด
- เราเลือกตลาดผิด: เล็กเกินไป
สิ่งที่เราต้องการไม่ใช่แค่ “การคำนวณที่ตรวจสอบได้ชนิดใดก็ได้” แต่ยึดติดกับ “ระบบที่ต้องมีการกระจายศูนย์, กลไกลงโทษ, ความปลอดภัยเชิงเศรษฐกิจแบบเข้ารหัสตั้งแต่วันแรก”
เราหวังให้ AVS กลายเป็น “บริการโครงสร้างพื้นฐาน” — คล้ายกับที่นักพัฒนาสร้าง SaaS (Software as a Service) ใคร ๆ ก็สร้าง AVS ได้
แต่จุดยืนแบบนี้จำกัดกลุ่มนักพัฒนาเป้าหมายอย่างมาก
สุดท้าย เราต้องเผชิญกับตลาดที่ “ขนาดเล็ก, ความคืบหน้าช้า, อุปสรรคสูง”: ผู้ใช้เป้าหมายน้อย, ต้นทุนการนำไปใช้สูง, ทั้งสองฝ่าย (ทีมและนักพัฒนา) ต้องใช้เวลาขับเคลื่อนโครงการนานมาก ไม่ว่าจะเป็นโครงสร้างพื้นฐาน EigenLayer, เครื่องมือพัฒนา หรือแต่ละ AVS บนระบบ ก็ใช้เวลาหลายเดือนหรือหลายปีกว่าจะสำเร็จ
เวลาผ่านไปเกือบสามปี: ปัจจุบันมีเพียง AVS หลัก ๆ สองตัวที่รันบนโปรดักชัน — คือ DIN (Decentralized Infrastructure Network) ของ Infura และ EigenZero ของ LayerZero อัตราการนำไปใช้แบบนี้ยังห่างไกลจากคำว่า “แพร่หลาย”
พูดตามตรง ตอนออกแบบเราคิดถึงกรณีที่ “ทีมอยากได้ความปลอดภัยเชิงเศรษฐกิจและโอเปอเรเตอร์กระจายศูนย์ตั้งแต่วันแรก” แต่ตลาดจริงกลับต้องการโซลูชันที่ “ค่อยเป็นค่อยไป และเน้นการใช้งานจริงมากกว่า”
- ข้อจำกัดทางกฎระเบียบ ทำให้เราต้อง “เงียบ”
เราเริ่มโครงการในช่วงสูงสุดของ “ยุค Gary Gensler” (หมายเหตุ: Gary Gensler คือประธาน SEC ของสหรัฐฯ ที่มีท่าทีเข้มงวดกับวงการคริปโต) ตอนนั้นบริษัทสเตคหลายเจ้าถูกสอบสวนและฟ้องร้อง
ในฐานะ “โปรเจกต์รีสเตค” คำพูดแทบทุกประโยคที่เราพูดในที่สาธารณะอาจถูกตีความว่า “แอบสัญญาผลตอบแทน” “โฆษณาผลประโยชน์” หรือแม้แต่โดนหมายศาล
หมอกควันด้านกฎระเบียบนี้กำหนดวิธีสื่อสารของเรา: ไม่สามารถออกมาพูดอะไรก็ได้ แม้จะโดนข่าวลบ, ถูกพาร์ทเนอร์โยนความผิด, หรือโดนโจมตีทางสังคม ก็อธิบายอะไรไม่ได้ทันที
เรายังไม่กล้าพูดง่าย ๆ ว่า “ความจริงไม่ใช่อย่างนั้น” — เพราะต้องชั่งน้ำหนักความเสี่ยงทางกฎหมายก่อน
ผลลัพธ์ก็คือ ในสภาพที่สื่อสารได้ไม่เต็มที่ เราก็เปิดตัวโทเค็นแบบล็อก ซึ่งตอนนี้มองย้อนกลับไป ถือว่าเสี่ยงอยู่ไม่น้อย
ถ้าคุณเคยรู้สึกว่า “ทีม Eigen ดูเลี่ยงประเด็น หรือเงียบผิดปกติ” ก็อาจมาจากสภาพกฎระเบียบแบบนี้ — โพสต์ผิดเพียงครั้งเดียวก็อาจเสี่ยงสูงเกินคาดคิด
- AVS รุ่นแรกทำให้แบรนด์เจือจาง
พลังของแบรนด์ Eigen ในระยะแรก ส่วนใหญ่เกิดจาก Sreeram (แกนหลักของทีม) — พลังบวก, มองโลกในแง่ดี, และความเชื่อที่ว่าทั้งระบบและคนจะดีขึ้นได้ สะสมความไว้วางใจให้ทีมมหาศาล
ทุนสเตคหลักพันล้านก็ยิ่งเสริมแรงศรัทธานี้
แต่การผลักดัน AVS รุ่นแรกแบบร่วมมือกัน กลับไม่สอดคล้องกับ “ระดับแบรนด์” ที่สร้างไว้ หลาย AVS แรกเสียงดังแต่ไล่ตามกระแส ไม่ได้เป็นตัวอย่าง AVS ที่ “เทคโนโลยีแข็งแกร่ง” หรือ “ซื่อสัตย์สูงสุด”
เมื่อเวลาผ่านไป ผู้คนเริ่มเอา “EigenLayer” ไปจับคู่กับ “กระแสฟาร์มเหรียญ, Airdrop ล่าสุด” ปัญหาโดนตั้งคำถาม, เบื่อ หรือแอนตี้ ส่วนใหญ่ย้อนกลับไปยังช่วงเวลานี้
ถ้าย้อนเวลาได้ ผมอยากเริ่มจาก “AVS น้อยแต่คุณภาพสูง” เลือกพาร์ทเนอร์ที่คู่ควรกับแบรนด์มากขึ้น ยอมรับการโปรโมตที่ “ช้ากว่า, กระแสน้อยกว่า”
- เทคโนโลยีที่หมกมุ่นกับ “Minimized Trust” เกินไป ทำให้ระบบซับซ้อนโดยใช่เหตุ
เราพยายามสร้าง “ระบบลงโทษแบบ Perfect Universal” — ต้องใช้ได้กับทุกกรณี, ยืดหยุ่น, ครอบคลุมทุกกรณี เพื่อให้ “ลดความไว้ใจ” ให้ได้มากที่สุด
แต่เมื่อเอามาใช้จริง กลับทำให้การพัฒนาผลิตภัณฑ์ช้าลง ต้องใช้เวลาอธิบายกลไกที่ “คนส่วนใหญ่ยังไม่พร้อมเข้าใจ” ซ้ำ ๆ แม้ตอนนี้ระบบลงโทษที่เปิดตัวมาเกือบปี เรายังต้องประชาสัมพันธ์อีกรอบ
พอมองย้อน กลยุทธ์ที่เหมาะสมน่าจะเป็น: ออกแบบระบบลงโทษแบบง่ายก่อน ให้ AVS ต่าง ๆ ได้ทดลองโมเดลที่เจาะจง แล้วค่อย ๆ เพิ่มความซับซ้อนของระบบ แต่เรากลับ “ดีไซน์ซับซ้อน” ตั้งแต่ต้น สุดท้ายต้องแลกทั้ง “ความเร็ว” และ “ความชัดเจน” …
