Google Cloud เข้าร่วมวงการ Puffer UniFi จะเติมเต็มก้าวสุดท้ายของ Based Rollup ได้หรือไม่?

การเข้ามาของบริษัทเทคโนโลยียักษ์ใหญ่ Web2 รายหนึ่ง ได้ผลักดันแนวคิดใหม่ที่ชื่อว่า "Gateway" ซึ่งก่อนหน้านี้มักปรากฏอยู่ในบริบททางเทคนิคเท่านั้น ให้เข้าสู่สายตาของสาธารณชน

เมื่อวันที่ 22 กันยายน Puffer ได้ประกาศความร่วมมือกับ Google Cloud โดย Google Cloud จะทำหน้าที่เป็นพันธมิตรด้านโครงสร้างพื้นฐานหลัก ดำเนินการ Gateway ผ่าน Puffer Preconf สนับสนุนชั้นการประมวลผลของ Puffer UniFi ช่วยจัดการธุรกรรม และให้ Execution Preconfirmation ก่อนที่ธุรกรรมจะถูกชำระบัญชีขั้นสุดท้ายบน Ethereum

ที่น่าสนใจยิ่งกว่านั้นคือ Puffer UniFi จะกลายเป็น Rollup แรกที่ใช้ Google Cloud Gateway

อย่างไรก็ตาม หากเพียงเข้าใจเรื่องนี้ว่าเป็นแค่ "ยักษ์ใหญ่ Web2 อีกรายที่เข้าสู่ Web3" ก็อาจพลาดส่วนที่น่าพูดคุยยิ่งกว่าที่อยู่เบื้องหลังความร่วมมือครั้งนี้

เนื่องจากบทบาทของ Google Cloud ในครั้งนี้ ไม่ใช่บทบาทรอบนอกในความหมายดั้งเดิมที่ให้พลังการประมวลผล การ托管โหนด หรือบริการคลาวด์แก่โปรเจกต์บล็อกเชน แต่ในทางกลับกัน กำลังเข้าสู่สถาปัตยกรรมการประมวลผลแบบเรียลไทม์ของ Puffer UniFi โดยตรง กลายเป็นหนึ่งในชั้น Gateway ที่เชื่อมโยงการประมวลผลธุรกรรม Preconfirmation และการชำระบัญชีขั้นสุดท้ายบน Ethereum

ซึ่งนำไปสู่คำถามที่ใหญ่ยิ่งกว่า: Puffer UniFi กำลังสร้างอะไรกันแน่? ทำไมจึงต้องมี Gateway? และทำไม Google Cloud จึงเลือกเข้าสู่ Ethereum จากตำแหน่งที่ค่อนข้างเป็นรากฐานนี้?

คำตอบอาจต้องเริ่มจากระยะใหม่ที่ Ethereum L2 กำลังก้าวเข้าสู่

1. Puffer UniFi: คำตอบหนึ่งสำหรับ Rollup ในครึ่งหลัง

หลังจากเข้าสู่ปี 2026 กลยุทธ์ Rollup ของ Ethereum อยู่ในช่วงเวลาที่ละเอียดอ่อนอย่างชัดเจน

นับตั้งแต่ Vitalik Buterin จุดกระแสการทบทวนเส้นทาง L2 ภารกิจทางประวัติศาสตร์ในระยะของ L2 ในฐานะเครื่องมือขยายขีดความสามารถของ Ethereum ก็ได้รับการประกาศว่าสิ้นสุดลงแล้วในระดับตลาดและความคิดเห็นสาธารณะ

คำถามหนึ่งเริ่มคมชัดขึ้นเรื่อย ๆ นั่นคือ เมื่อ L2 ไม่ใช่เพียงเครื่องมือขยายขีดความสามารถที่แบ่งเบาภาระความแออัดให้ L1 อีกต่อไป แล้วมันควรนิยามการมีอยู่ของตัวเองอย่างไร? และควรสร้างความสัมพันธ์ด้านความปลอดภัย การจัดลำดับ สภาพคล่อง และความสามารถในการประกอบกันใหม่กับ L1 ให้เป็นเอกภาพมากขึ้นได้อย่างไร?

Puffer UniFi กำลังพยายามเสนอคำตอบหนึ่งในนั้น

Puffer UniFi ไม่ได้เลือกที่จะเดินหน้าใช้ระบบจัดลำดับแบบรวมศูนย์ที่ค่อนข้างเป็นอิสระต่อไป แต่เลือกเดินสู่ Based Rollup: ให้สิทธิ์ในการจัดลำดับของ Rollup ยึดโยงกับ Ethereum L1 โดยตรงมากขึ้น ให้ระบบผู้ตรวจสอบของ Ethereum มีส่วนร่วมในการจัดลำดับ และสืบทอดความปลอดภัยและความเป็นกลางของ Ethereum เองในที่สุด

นี่ไม่ได้หมายความว่า L2 ได้สูญเสียความหมายไปแล้ว

พูดให้แม่นยำกว่านั้น เมื่อภารกิจเฉพาะระยะของการขยายขีดความสามารถเพียงอย่างเดียวค่อย ๆ สำเร็จลุล่วง Rollup เริ่มต้องตอบคำถามเกี่ยวกับตำแหน่งคุณค่าของตัวเองใหม่: ในอนาคตจะยังคงดำรงอยู่เป็นชั้นการประมวลผลทั่วไปต่อไป หรือจะกลายเป็นโครงสร้างพื้นฐานแอปพลิเคชันที่ทำงานร่วมกับ Ethereum อย่างใกล้ชิดมากขึ้น โดย围绕แอปพลิเคชัน สถานการณ์ใช้งาน และประสบการณ์ผู้ใช้ที่ชัดเจนยิ่งขึ้น?

ท้ายที่สุด สำหรับ Ethereum เมื่อ 5 ปีก่อน L2 scaling ถือเป็นเส้นทางที่สมจริงและประสบความสำเร็จอย่างมาก แต่ในวันนี้ 5 ปีต่อมา สินทรัพย์และสภาพคล่องกระจัดกระจายอยู่ในเกาะโดดเดี่ยวหลายสิบแห่ง Rollup จำเป็นต้อง reposition ตัวเองใหม่ เช่น ทิศทาง appchain ที่มีสถานการณ์ใช้งานและขอบเขตธุรกิจชัดเจนซึ่ง Vitalik สนับสนุน

ความหมายของ Based Rollup อยู่ที่การพยายามปรับความสัมพันธ์นี้ใหม่

แนวคิดหลักไม่ซับซ้อน เนื่องจาก Rollup ยังคงพึ่งพา Ethereum ในการชำระบัญชีและการตรวจสอบความปลอดภัยขั้นสุดท้าย ดังนั้นสิทธิ์ในการจัดลำดับก็สามารถกลับสู่ Ethereum L1 โดยตรงมากขึ้น ให้ระบบผู้ตรวจสอบของ Ethereum รับผิดชอบการจัดลำดับ Rollup ในทางทฤษฎีไม่เพียงสามารถขจัดความพึ่งพา Rollup ต่อ sequencer เดียว แต่ยังสามารถบรรลุความสามารถในการประกอบกันแบบซิงโครไนซ์ระหว่าง L1 และ L2 ได้อย่างแท้จริง

กล่าวอีกนัยหนึ่ง Based Rollup ไม่ได้เสนอ "การสร้าง L2 ที่เร็วกว่าขึ้นมาอีกเส้น" แต่เป็นคำตอบที่ใกล้เคียงเส้นทางดั้งเดิมของ Ethereum มากกว่า——ทำให้การขยายขีดความสามารถไม่หมายถึงการแตกแยกอีกต่อไป ทำให้การเติบโตของ L2 ย้อนกลับไปหล่อเลี้ยงความปลอดภัยและคุณค่าของ L1

นี่เป็นทิศทางที่ในทางทฤษฎีแทบไม่มีที่ติ แต่ปัญหาคือ คำตอบที่ดีที่สุดในทางทฤษฎีไม่ได้เท่ากับระบบที่ใช้งานได้จริงในความเป็นจริงโดยอัตโนมัติ:

• ข้อจำกัดจริงประการแรกคือความเร็ว เวลาออกบล็อกของ Ethereum L1 อยู่ที่ประมาณ 12 วินาที หากการจัดลำดับ Rollup ทำตามจังหวะของ L1 อย่างสมบูรณ์ ทุกธุรกรรมจะต้องรออย่างน้อยหนึ่งบล็อก L1 จึงจะได้รับการยืนยันที่ค่อนข้างเชื่อถือได้ การโอนทั่วไปอาจยอมรับได้ แต่สำหรับการชำระเงินทันที สมุดคำสั่ง สัญญาซื้อขายล่วงหน้าแบบถาวร และแอปพลิเคชัน DeFi ความถี่สูงนั้น เห็นได้ชัดว่าไม่สามารถเทียบเคียงกับผลตอบสนองระดับต่ำกว่าวินาทีที่ sequencer แบบรวมศูนย์มอบให้ได้ (อ่านเพิ่มเติม《Preconfs วิวัฒนาการ: จาก "แพตช์" สู่ "โครงสร้างพื้นฐาน" UniFi AVS ส่งผลต่อกฎเกณฑ์ของ Based Rollup อย่างไร?》);
• ข้อจำกัดประการที่สองคือภาระการประมวลผล เป็นที่ทราบกันดีว่า Ethereum ยืนหยัดลดเกณฑ์การตรวจสอบมาโดยตลอด มุ่งมั่นให้ฮาร์ดแวร์ทั่วไปและโหนดส่วนบุคคล更多สามารถมีส่วนร่วมในฉันทามติเครือข่าย แต่ Based Rollup กำหนดให้ผู้ตรวจสอบ L1 รับบทบาทการจัดลำดับความถี่สูงและการประมวลผลที่มีความหน่วงต่ำโดยตรง ซึ่งย่อมผลักดันเกณฑ์ด้านฮาร์ดแวร์ เครือข่าย และการดำเนินงานของผู้ตรวจสอบให้สูงขึ้น และอาจสร้างแรงกดดันด้านการรวมศูนย์ใหม่ในชั้นการประมวลผลแทน;
• ข้อจำกัดประการที่สามมาจากโครงสร้างแรงจูงใจ สำหรับทีม L2 หลายแห่ง หากการย้ายไปสู่สถาปัตยกรรม Based หมายถึงความซับซ้อนทางเทคนิคที่เพิ่มขึ้นและผลตอบแทนที่ไม่เพียงพอ การรักษา sequencer แบบรวมศูนย์ของตัวเองไว้ก็ยังเป็นทางเลือกที่สมเหตุสมผลกว่า;

ดังนั้น ปัญหาของ Based Rollup ไม่เคยเป็นเรื่องทิศทางที่ไม่ถูกต้อง แต่ขาดโครงสร้างพื้นฐานที่เป็นจริงอีกชั้นหนึ่งก่อนจะใช้งานได้จริง——ตราบใดที่ระบบถูกล็อกด้วยจังหวะ 12 วินาทีของ L1 อย่างสมบูรณ์ ก็ยากที่จะรักษาความเร็วไว้ได้ และหากต้องการรักษาความเป็นกลางของ mainnet ไว้โดยไม่รวมศูนย์ใหม่ พร้อมกับได้รับประสบการณ์การโต้ตอบที่ใกล้เคียง sequencer แบบรวมศูนย์ ก็จำเป็นต้องนำการแบ่งบทบาทใหม่เข้ามาในชั้นการประมวลผล

นี่ก็เป็นความขัดแย้งหลักที่ Puffer UniFi ต้องแก้ไข

Puffer Preconf ถูกนำเข้ามาในสแตกเทคโนโลยีหลักของ Puffer UniFi ภายใต้บริบทนี้——ในฐานะบริการ preconfirmation ที่สร้างบน EigenCloud (เดิมคือ EigenLayer) สิทธิ์ในการจัดลำดับยังคงยึดโยงกับ Ethereum L1 แต่การจัดลำดับประสิทธิภาพสูง การตอบสนองความหน่วงต่ำ และการ preconfirm การประมวลผล ไม่จำเป็นต้องให้ L1 Validator ทำเองทั้งหมด

กล่าวอีกนัยหนึ่ง หาก Based Rollup ตอบคำถามว่า Puffer UniFi "พึ่งพาใครในการจัดลำดับและชำระบัญชีขั้นสุดท้าย" แล้ว Puffer Preconf ก็แก้ปัญหา "ก่อนการชำระบัญชีขั้นสุดท้าย ผู้ใช้จะได้รับประสบการณ์การประมวลผลแบบเรียลไทม์และเชื่อถือได้อย่างไร"

และนี่ก็เป็นจุดเริ่มต้นของการทำความเข้าใจ Gateway

2. การประมวลผลแบบเรียลไทม์: ทำไม Puffer UniFi ต้องมี Preconf?

ก่อนทำความเข้าใจ Gateway ต้องเข้าใจก่อนว่า Preconfirmation กำลังสัญญาอะไรกันแน่

ในความเป็นจริง ใน L2 กระแสหลัก เหตุผลที่ผู้ใช้สามารถเห็นผลตอบสนองของธุรกรรมได้อย่างรวดเร็ว มักเป็นเพราะ sequencer แบบรวมศูนย์ให้ soft guarantee ก่อน บอกคุณว่าธุรกรรมนี้เข้าคิวแล้ว ส่วนหน้าจอก็แสดงผลการประมวลผลอย่างรวดเร็ว ทำให้ผู้ใช้รู้สึกในประสบการณ์ว่า "ยืนยันแล้ว"

แต่ในทางเทคนิคแล้ว ผลตอบสนองที่รวดเร็วนี้อาศัยความไว้วางใจต่อ sequencer เพียงตัวเดียวเป็นหลัก

เมื่อ sequencer ล่ม มีความหน่วง ทำความชั่ว หรือเผชิญการตรวจสอบ คำสัญญานี้มักขาดกลไกความรับผิดชอบทางเศรษฐกิจและความรับผิดชอบที่ตรวจสอบได้ที่แข็งแกร่งเพียงพอ กล่าวอีกนัยหนึ่ง ความ "เร็ว" ของ Rollup แบบดั้งเดิมส่วนใหญ่มาจากชื่อเสียงของ sequencer เอง

สำหรับ Puffer UniFi แล้ว นี่เห็นได้ชัดว่าไม่เพียงพอ และสิ่งที่ Puffer Preconf ต้องการแก้ไขก็คือปัญหานี้

มันพยายามยกระดับ "การยืนยันอย่างรวดเร็ว" จากการไว้วางใจผู้ดำเนินการรายเดียว ไปสู่คำมั่นสัญญาการประมวลผลที่ได้รับการสนับสนุนจากหลักประกันทางเศรษฐกิจ คำมั่นสัญญาที่ลงนาม และกลไกความรับผิดชอบ——นี่ไม่ใช่แค่ทำให้ Puffer UniFi เร็วขึ้น แต่ต้องทำให้ความ "เร็ว" นี้เชื่อถือได้

หากต้องการเข้าใจสถาปัตยกรรมนี้ ต้องมองการแบ่งบทบาทให้ชัด

ในการออกแบบของ Puffer Preconf ผู้ตรวจสอบ L1 ยังคงเป็นแหล่งที่มาขั้นสุดท้ายของสิทธิ์ในการจัดลำดับ และเป็นจุดยึดโยงของความปลอดภัยและความเป็นกลางของ Ethereum แต่ไม่จำเป็นต้องดำเนินระบบจัดลำดับประสิทธิภาพสูงด้วยตัวเอง และไม่จำเป็นต้องรับภาระงานประมวลผลความหน่วงต่ำทั้งหมดโดยตรง ในทางกลับกัน ผ่านกลไก restaking และการมอบหมาย ผู้ตรวจสอบสามารถมอบงานที่ซับซ้อนนี้ให้ Gateway ที่เชี่ยวชาญกว่า โดยให้ Gateway รับหน้าที่ Sequencing และ Execution Pre-Confirmation แทน

กล่าวอีกนัยหนึ่ง ผู้ที่รับหน้าที่จัดลำดับและ preconfirmation จริง ๆ คือบทบาทใหม่ที่ชื่อ Gateway

มันไม่ใช่แค่การเปลี่ยนชื่อของ Sequencer แบบรวมศูนย์ดั้งเดิม และไม่ใช่ "ปลั๊กเร่งความเร็ว" ที่ติดเพิ่มกับ Rollup แต่มัน更像是ชั้นตัวแทนการประมวลผลระดับมืออาชีพที่ได้รับมอบหมายให้รับผิดชอบการจัดลำดับและ preconfirmation ภายใต้อธิปไตยของ L1:

• ในด้านหนึ่ง ช่วยให้ L1 Proposer ให้บริการจัดลำดับและ preconfirmation ที่มีประสิทธิภาพสูงขึ้น;
• ในอีกด้านหนึ่ง ผ่านกลไกการวางหลักประกัน การลงนามคำมั่นสัญญา การริบ และการแบ่งสรรผลตอบแทน ก็ป้องกันตัวเองไม่ให้กลายเป็นโหนดรวมศูนย์ใหม่ที่ไร้ข้อจำกัด;

Gateway ทำให้ผู้ตรวจสอบไม่ต้องดำเนินระบบจัดลำดับประสิทธิภาพสูงด้วยตัวเอง แต่ความเป็นเจ้าของสิทธิ์ในการจัดลำดับขั้นสุดท้ายยังคงยึดโยงกับ Ethereum L1

นี่ก็อธิบายว่าทำไม Puffer จึงเน้น Execution Pre-Confirmation ไม่ใช่แค่ Inclusion Promise: Inclusion promise เพียงสัญญาว่าธุรกรรมนี้จะถูกใส่ในบล็อก ส่วน Execution Preconfirmation แก้ปัญหาเพิ่มเติมว่า "ธุรกรรมนี้จะถูกประมวลผลตามสถานะที่สัญญาไว้ล่วงหน้าหรือไม่"

ความแตกต่างนี้สำคัญอย่างยิ่งสำหรับแอปพลิเคชันบนห่วงโซ่มูลค่าสูง

ยกตัวอย่าง DEX สัญญาซื้อขายล่วงหน้าแบบถาวร สำหรับสถานการณ์เช่นนี้ สิ่งที่ผู้ใช้กลัวที่สุดไม่ใช่คำสั่งไม่ถูกบรรจุในบล็อก แต่ถึงแม้ถูกบรรจุแล้ว ราคาซื้อขายขั้นสุดท้าย ลำดับการซื้อขาย หรือสถานะการชำระบัญชีกลับคลาดเคลื่อนไป ในบริบทนี้ Execution Preconf สามารถรับประกันได้ว่าผู้ใช้จะซื้อขายตามสถานะที่เห็นตอนส่งคำสั่ง ไม่ต้องรับ slippage เพิ่มเติมหรือผลการประมวลผลที่ไม่คาดคิด

ตรรกะเดียวกันยังใช้ได้กับสมุดคำสั่งราคาจำกัดกลางบนห่วงโซ่ กระแสคำสั่งสถาบัน การชำระเงิน การชำระบัญชีเงินกู้ การอ่านสถานะแบบเรียลไทม์ข้ามชั้น เป็นต้น CLOB ต้องการลำดับการประมวลผลที่แน่นอนและผลตอบสนองความหน่วงต่ำ การซื้อขายสถาบันต้องการคำมั่นสัญญาสถานะที่สามารถ追究ความรับผิดชอบได้ การชำระเงินและการกระจายเงินเดือนต้องการประสบการณ์การชำระบัญชีที่คาดเดาได้ ส่วนระบบชำระบัญชีต้องการลดการคลาดเคลื่อนของสถานะให้มากที่สุดในสภาวะตลาดผันผวนรุนแรง

แน่นอน คำมั่นสัญญาที่แข็งแกร่งใด ๆ ต้องมาพร้อมข้อจำกัดที่แข็งแกร่ง ในสถาปัตยกรรมอย่าง Puffer Preconf ความน่าเชื่อถือของ Gateway ไม่ได้มาจากการที่มันอ้างว่าตัวเองเชื่อถือได้ แต่มาจากการที่มันต้องรับผลทางเศรษฐกิจจากการกระทำของตัวเอง ที่นี่มีข้อจำกัดอย่างน้อยสองชั้น:

Gateway ต้องวางหลักประกันจึงจะเข้าสู่การจัดตาราง lookahead ได้ หาก Gateway ตัวใดไม่ส่ง batch ไปยัง L1 ตามกำหนดภายในหน้าต่างที่ตัวเองรับผิดชอบ Gateway ตัวถัดไปสามารถส่งแทนได้ และกระตุ้นการริบต่อตัวแรก;

จากมุมมองของผู้ใช้ หากธุรกรรมที่มีคำมั่นสัญญา preconfirmation สุดท้ายไม่ได้รับการ兑现 ผู้ใช้สามารถใช้ใบเสร็จคำมั่นสัญญาที่มีลายเซ็นไปเรียกร้องหรือขอคืนเงินได้;

ต้องสังเกตว่ากลไกการริบที่เฉพาะเจาะจงจะเปลี่ยนแปลงไปตามระยะของเครือข่ายและเวอร์ชันการใช้งาน ดังนั้นคำกล่าวที่แม่นยำกว่าคือไม่ใช่ "Gateway ถูก slashing ในทุกสถานการณ์แล้ว" แต่ทิศทางการออกแบบของ Puffer Preconf คือการใช้หลักประกัน รางวัล การลงโทษ และความรับผิดชอบจากลายเซ็น แทนที่คำมั่นสัญญาอ่อนที่ขาดข้อจำกัดภายใต้ sequencer แบบรวมศูนย์ดั้งเดิม

นอกจากสถาปัตยกรรมทางเทคนิคแล้ว ปัญหาอ