เมื่อไหร่คนหนึ่งจะแน่ใจว่าธุรกรรม L2 (เลเยอร์ 2) จะถูกรวมอยู่ในบล็อก? เมื่อไหร่คนหนึ่งจะแน่ใจว่ารายได้จากธุรกรรม L2 จะไม่ถูกละทิ้งเนื่องจาก Re-org?

บทความนี้จะแนะนำกระบวนการทั้งหมดของการดำเนินการธุรกรรม L2 และวิเคราะห์ประสิทธิภาพด้านความปลอดภัยในแต่ละขั้นตอนของกระบวนการธุรกรรม

ความรู้พื้นฐานก่อน

• กระบวนการทั้งหมดของธุรกรรม L1 (Layer 1)
• เหตุผลและผลกระทบของเหตุการณ์ Re-org
• เข้าใจบทบาทและวิธีการทำงานในสถาปัตยกรรม Ethereum PBS ปัจจุบัน
• ความแตกต่างระหว่าง Optimistic Rollup และ Validity (ZK) Rollup

เข้าใจธุรกรรม L1

กระบวนการธุรกรรม

หลังจากผู้ใช้ออกและลงนามในธุรกรรมมันจะถูกส่งไปยังเครือข่าย p2p เพื่อรอการรวมไว้ในบล็อกโดยนักขุดภายใต้กลไกฉันทามติ Proof of Work (PoW) หรือผู้เสนอภายใต้กลไกฉันทามติ Proof of Stake (PoS) เมื่อผู้ใช้สังเกตเห็นว่าธุรกรรมของพวกเขารวมอยู่ในบล็อกล่าสุดยังไม่มั่นใจว่าธุรกรรมจะถูกบันทึกไว้อย่างถาวรในประวัติของบล็อกเชน ความไม่แน่นอนนี้เกิดจากความเป็นไปได้ของ "Re-org" (การปรับโครงสร้างองค์กร) ที่เกิดขึ้นบนบล็อกเชน ผู้ใช้ต้องรอจนกว่าความเป็นไปได้ที่จะเกิดขึ้น Re-org จะต่ําพอที่จะมั่นใจได้ว่าธุรกรรมของพวกเขาจะถูกบันทึกไว้อย่างถาวรในประวัติศาสตร์ของบล็อกเชน

กระบวนการดำเนินการธุรกรรม L1 อธิบายด้วยภาพ

แม้ว่าธุรกรรมจะถูกรวมในบล็อกแล้ว การ Re-org ก็ยังอาจเกิดขึ้นได้ ซึ่งหมายความว่าการยืนยันสามารถรับรองได้เพียงเมื่อความน่าจะเป็นของ Re-org เริ่มน้อยลง

ความน่าจะเป็นและความต้นทุนของการ Re-org ขึ้นอยู่กับขั้นตอนของ consensus algorithm และมูลค่าของสินทรัพย์ในตลาดของแต่ละ blockchain บทความนี้จะไม่สนใจวิธีการคำนวณค่าใช้จ่ายสำหรับ Re-org

เข้าใจธุรกรรม L2

กระบวนการธุรกรรม

ผู้ใช้ L2 สร้างและลงนามธุรกรรม โดยทั่วไปจะส่งโดยตรงไปยัง Sequencer ซึ่งจะรวมธุรกรรมเหล่านี้ในบล็อก L2 ต่อมา เมื่อ Sequencer โพสต์ข้อมูลบล็อก L2 กลับไปยัง L1 ผ่านธุรกรรม L1 ผู้ใช้จะเห็นว่าธุรกรรมของตนถูกรวมในบล็อก L2 ล่าสุด

อย่างไรก็ตาม สิ่งสำคัญที่ต้องทราบคือ เนื่องจากข้อมูลบล็อก L2 ถูกโพสต์ไปยัง L1 ผ่านธุรกรรม L1 การที่ L1 Re-org เกิดขึ้นยังเป็นไปได้ ซึ่งอาจส่งผลให้บล็อก L2 ไม่ได้ถูกบันทึกอย่างถาวรในประวัติบล็อกเชน สถานการณ์นี้เหมือนกับ L2 Re-org ดังนั้นผู้ใช้ต้องรอจนกว่าความน่าจะเป็นของ L1 Re-org จะต่ำพอที่จะมั่นใจว่าธุรกรรมของพวกเขาจะถูกบันทึกอย่างถาวรในประวัติบล็อกเชน

กระบวนการทำธุรกรรม L2 อธิบาย

ผู้ใช้ต้องรอให้ธุรกรรมของพวกเขาถูกรวมอยู่ในบล็อก L2 ก่อน จากนั้นให้บล็อก L2 โพสต์ไปยัง L1 ผ่านธุรกรรม L1 และสุดท้ายรอให้ธุรกรรม L1 ได้รับการสรุป

แม้ว่าธุรกรรม L2 จะเกิดเวลารอเพิ่มเติมสำหรับการรวมอยู่ในบล็อก L2 โดย Sequencer เมื่อเปรียบเทียบกับธุรกรรม L1 แต่รอดังกล่าวทั่วไปจะสั้นหากความจุบล็อก L2 ใหญ่และการสร้างบล็อกเร็ว โดยทั่วไปรอนี้คือช่วงเวลารอหลักสำหรับการยืนยันธุรกรรม L1 ดังนั้นประสบการณ์ผู้ใช้โดยรวมของธุรกรรม L1 และ L2 คล้ายกัน

การยืนยันก่อน/การยืนยันเร็ว/การยืนยันอย่างอ่อน

ผู้ใช้ควรตรวจสอบด้วยตนเองว่าธุรกรรม L2 ของพวกเขาพร้อมกับบล็อก L2 ได้รับการรวมอยู่ในบล็อก L1 และรอจนกระทั่งความน่าจะเป็นของ Re-org ต่ำมากพอที่จะเชื่อว่าธุรกรรม L2 ของพวกเขาได้รับการรวมแล้ว

แต่ถ้าผู้ใช้เต็มใจที่จะไว้วางใจซีเควนเซอร์ล่ะ? ซีเควนเซอร์สามารถดําเนินการโดยทีมพัฒนา L2 หรือสถาบันที่มีชื่อเสียง หาก Sequencer รับรองผู้ใช้ทันทีเมื่อได้รับธุรกรรมว่าพวกเขาจะรวมอยู่ในบล็อกเฉพาะการรับประกันนี้อาจเพียงพอสําหรับผู้ที่ต้องการไว้วางใจ Sequencer มันคล้ายกับผู้ใช้ที่ไว้วางใจแอปพลิเคชันกระเป๋าเงินของพวกเขาและไม่ตรวจสอบ Etherscan เพื่อยืนยันหลังจากได้รับแจ้งการรวมธุรกรรม

การรับประกันเช่นนี้ที่ Sequencer ให้เรียกว่า Pre-Confirmation, Fast Confirmation, หรือ Soft Confirmation ถือเป็นการรับประกัน "เบื้องต้น" หรือ "เบื้องหลัง" ของการรวมธุรกรรม โดยไม่ต้องการให้ธุรกรรม L2 ถูกรวมอยู่ในบล็อก L1 อย่างไรก็ตาม นี่เป็นการยืนยันทางบรรพชนจาก Sequencer เท่านั้น ซึ่งอาจลืมเนื่องจากข้อบกพร่องหรือถูกแตกออกโดยมาลัยชั่น Sequencer ที่ร้ายแรง ซึ่งมีผลเสียให้เกิดการโจมตีหลายรอบ

ต่อมาเราจะแนะนำวิธีต่าง ๆ ที่สถานะการรวมธุรกรรม L2 ถูกนำเสนอ

สถานะการรวมธุรกรรม Arbitrum/Optimism

ขณะนี้ผู้ใช้บน Arbitrum หรือ Optimism สามารถได้รับใบเสร็จการทำธุรกรรมเกือบทันทีหลังจากส่งธุรกรรม ทำให้ทราบผลลัพธ์ของการดำเนินการทราบว่า Sequencer ได้ทำการเรียงลำดับและจำลองธุรกรรมในระดับท้องถิ่นแล้ว และมอบให้ผู้ใช้ก่อนการยืนยัน

เรียนรู้เพิ่มเติม

สำหรับข้อมูลที่เป็นรายละเอียดมากขึ้นเกี่ยวกับวงจรชีวิตการทำธุรกรรม Arbitrum โปรดอ้างอิงที่เอกสารประกอบการทางการ: https://docs.arbitrum.io/tx-lifecycle

สำหรับข้อมูลที่ละเอียดเพิ่มเติมเกี่ยวกับขั้นตอนการทำธุรกรรมใน Optimism โปรดอ้างถึงเอกสารทางการ: https://community.optimism.io/docs/protocol/txn-flow/#posting-to-l1

สถานะรายได้จากการซื้อขายสำหรับ Arbitrum/Optimism

ในปัจจุบัน หลังจากที่ผู้ใช้ส่งธุรกรรมบน Arbitrum หรือ Optimism พวกเขาสามารถรับใบเสร็จธุรกรรม (Transaction Receipt) เกือบทันทีซึ่งจะประกอบด้วยผลลัพธ์ของการดำเนินการธุรกรรมนี้ นี้หมายความว่า Sequencer ได้เรียงลำดับธุรกรรมในท้องถิ่นและจำลองมันอีกครั้ง ใบเสร็จธุรกรรมนี้คือการยืนยันก่อนการยืนยันที่ให้กับผู้ใช้

เรียนรู้เพิ่มเติม

สำหรับข้อมูลที่เป็นรายละเอียดมากขึ้นเกี่ยวกับวงจรชีวิตการทำธุรกรรมของ Arbitrum คุณสามารถคัดลอกลิงก์ด้านล่างไปยังเบราว์เซอร์เพื่ออ้างอิงเอกสารอย่างเป็นทางการ:

https://docs.arbitrum.io/tx-lifecycle

สำหรับข้อมูลที่เป็นรายละเอียดมากขึ้นเกี่ยวกับวงจรชีวิตการทำธุรกรรมของ Optimism คุณสามารถคัดลอกลิงก์ด้านล่างไปที่เบราว์เซอร์และอ้างอิงไปยังเอกสารอย่างเป็นทางการ:

https://community.optimism.io/docs/protocol/txn-flow/#posting-to-l1

ตรวจสอบสถานะรายได้จากรายการธุรกรรมบน Arbitrum

ธุรกรรมที่เห็นบน Arbitrum Explorer จะรวมถึง ธุรกรรมก่อนการยืนยัน กล่าวคือ ธุรกรรมที่ยังไม่ได้ถูกอัปโหลดไปยัง L1 สำหรับธุรกรรมนี้ที่แสดงในรูปด้านล่าง คุณสามารถเห็นเครื่องหมาย Confirmed by Sequencer ถัดจากหมายเลขบล็อก 145353000:

ภาพด้านบนแสดงธุรกรรมที่ได้รับการยืนยันเฉพาะโดย Sequencer แต่ยังไม่ได้ถูกอัปโหลดไปที่ L1 โดย

หากเป็นธุรกรรมที่ได้รับการอัปโหลดไปยัง L1 ตามที่แสดงในรูปด้านล่าง สถานะของมันได้เปลี่ยนเป็น 69 การยืนยันบล็อก L1 ซึ่งหมายความว่าได้รับการอัปโหลดไปยัง L1 และบล็อก Layer1 ที่ประกอบด้วยข้อมูลธุรกรรมได้มีการมีอยู่ 69 บล็อกต่อมา:

บล็อก L1 ที่มีข้อมูลธุรกรรมนี้มีบล็อกตามมาถึง 69 บล็อกแล้ว ยิ่งมีบล็อกตามมามากเท่าไร มันก็จะปลอดภัยมากขึ้น

หรือสำหรับธุรกรรมนี้ตามที่แสดงในภาพหน้าจอด้านล่าง บล็อก L1 ที่มีข้อมูลของธุรกรรมนี้มีบล็อกตามมาอยู่แล้ว 6174 บล็อก ซึ่งถือว่าปลอดภัยมากแล้ว

แต่จริง ๆ แล้ว สิ่งที่สามารถทำได้ดีกว่านี้คือ นำเสนอร่วมกับข้อมูล Finality ของ L1

การแจ้งให้ผู้ใช้ทราบว่ามีการยืนยันบล็อก L1 กี่รายการนั้นมีประโยชน์จำกัดสำหรับผู้ใช้ เนื่องจากผู้ใช้ต้องเข้าใจและคำนวณระดับความปลอดภัยที่แทนโดยจำนวนการยืนยันบล็อก เเละเนื่องจาก Layer1 (นั่นคือ Ethereum) มีกลไก Finality เหมือน Casper FFG อยู่เเล้ว Explorer สามารถแสดงถึงว่าบล็อก Layer1 ได้รับการ Finalized ใน Layer1 โดยตรง ณ ปัจจุบัน Explorer ของ Optimism ได้นำฟังก์ชันดังกล่าวมาใช้งาน

ตรวจสอบสถานะใบเสร็จธุรกรรมบน Optimism

ธุรกรรมที่เห็นบน Optimism Explorer อาจรวมถึงบางรายการที่ถูกทำเครื่องหมายว่า Pre-Confirmation ซึ่งแสดงว่ายังไม่ได้โพสต์ไปยังเลเยอร์ 1 (L1) ตามที่แสดงด้านล่าง ธุรกรรมกับหมายเลขบล็อก 111526300 ถูกติดแท็กว่า "Confirmed by Sequencer"

ธุรกรรมที่ยืนยันโดยตัวจัดเรียง แต่ยังไม่ได้โพสต์ลงบน L1

ในปัจจุบัน ตัวสำรวจดูเหมือนจะขาดคำจำกัดความชัดเจนสำหรับ "Confirmed by Sequencer," ซึ่งบ่งชี้ว่า "การยืนยันโดย Sequencer คือเทียบเท่ากับการยืนยันบล็อกบางรายบน L1" ซึ่งนั้นแปลว่า "การยืนยันโดย Sequencer" หมายถึงธุรกรรมได้ถูกโพสต์ไปยัง L1 และมีบล็อกหลายๆ ตามหลัง

อย่างไรก็ตาม ธุรกรรมที่ปรากฏขึ้นเร็ว ๆ ก็ถูกแสดงให้เห็นเช่นกันเป็น “ได้รับการยืนยันโดยตัวต่อตัว” และแม้ธุรกรรมจากหลายวันก่อนๆ ที่ผ่านไปได้ระยะเวลาทดสอบยังคงอยู่ในสถานะ “ได้รับการยืนยันโดยตัวต่อตัว” อยู่:

ธุรกรรมจากวันก่อนหน้ายังคงอยู่ในสถานะ "ยืนยันโดยซีเควนเซอร์"

หมายเหตุการอ่าน: สถานการณ์นี้อาจเกิดจาก Explorer นําเสนอตัวบ่งชี้สถานะที่แตกต่างกันในสถานที่ต่างๆ: "ยืนยันโดย Sequencer" ถัดจากหมายเลขบล็อกแจ้งให้ผู้ใช้ทราบว่าบล็อกได้รับการยืนยันโดย Sequencer ในการตรวจสอบสถานะ post-L1 ผู้ใช้ต้องอ้างถึงข้อมูลอื่น ๆ เช่นรายละเอียด "L1 State Batch" ที่กล่าวถึงด้านล่าง

นอกจากนี้ ตามที่แสดงในภาพหน้าจอด้านล่าง ธุรกรรมที่ได้ถูกโพสต์ไปยัง L1 รวมถึงสองส่วนเพิ่มเติมของข้อมูล: “L1 State Batch Index” และ “L1 State Root Submission Tx Hash” รายละเอียดเหล่านี้แสดงถึง State Batch ที่ธุรกรรม L2 รวมอยู่และผ่านธุรกรรม L1 ใดที่ State Batch นี้ถูกโพสต์ไปยัง L1:

เมื่อคลิกที่ “State Batch 3480,” สถานะของมันจะแสดงเป็น Finalized ซึ่งสอดคล้องกับสถานะ Finalized บน L1 (หรือ Ethereum mainnet) ซึ่งเป็นสถานะที่มีความปลอดภัยมาก ที่ได้รับหลักจากโหวตจาก validators ในระหว่าง 2 epochs

△ สถานะ Batch 3480 ได้รับการรวมอยู่ในบล็อก L1 18457449 และบล็อก 18457449 ได้รับการ Finalized แล้ว

แหล่งที่มา: https://etherscan.io/block/18457449

หาก Batch ได้โพสต์แล้ว แต่ยังไม่ได้ยืนยันบน L1 จะแสดงเป็น Unfinalized:

สถานะชุด 3494 ถึงแม้จะโพสต์ไปที่ L1 แต่ถูกรวมอยู่ในบล็อค L1 ที่ยังไม่ได้ทำการสรุป

เมื่อเปรียบเทียบกับ Arbitrum Explorer โอพทิมิสึม เอกซ์พลอเรอร์ให้ข้อมูลที่ละเอียดมากขึ้น (State Batch) และเชื่อมโยงข้อมูล L1 Finality โดยตรงไปยัง L2 Explorer ทำให้ผู้ใช้ทราบว่าบล็อก L1 ได้รับการ Finalized หรือไม่ โดยไม่ต้องทำการตัดสินใจเองจากจำนวนของ Block Confirmations สำหรับระดับความปลอดภัย

สถานะรายได้จากธุรกรรม StarkNet

ปัจจุบันเมื่อผู้ใช้ส่งธุรกรรมบน StarkNet พวกเขาสามารถสืบค้นใบเสร็จรับเงินธุรกรรมได้อย่างรวดเร็ว อย่างไรก็ตาม ใบเสร็จมักจะแสดงสถานะธุรกรรมเป็น RECEIVED สถานะนี้บ่งชี้ว่าโหนดได้รับธุรกรรมและหลังจากการตรวจสอบไม่พบปัญหา ธุรกรรมกําลังรอที่จะรวมอยู่ในบล็อก L2 โดย Sequencer และดําเนินการ ธุรกรรมในสถานะ RECEIVED จะยังไม่มีผลลัพธ์ใดๆ จากการดําเนินการ ผู้ใช้สามารถตรวจสอบความคืบหน้าของธุรกรรมได้โดยดูสถานะธุรกรรมที่แสดงบน StarkNet Explorer

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

เอกสารทางการ:วงจรชีวิตการทำธุรกรรมของ StarkNet

ธุรกรรมที่เห็นบน Starkscan, ตัวสำรวจ StarkNet, รวมทั้งรวมถึง ธุรกรรมก่อนการยืนยัน อย่างที่แสดงในธุรกรรมต่อไปนี้ สถานะปัจจุบันคือ "ได้รับการยอมรับบน L2" ซึ่งแสดงว่ามันได้รับการจัดคิวโดยตัวเรียงเข้าไปในบล็อก L2:

“Accepted on L2” หมายความว่าว่าได้รับคิวโดย Sequencer เข้าไปในบล็อก L2 แต่ยังไม่ได้อัปโหลดไปยัง L1

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

ธุรกรรมได้รับและตรวจสอบแล้ว

การทำธุรกรรมกำลังดำเนินการโดยตัวควบคุมชุดข้อมูล

เมื่อข้อมูลการทำธุรกรรมถูกอัปโหลดไปยัง L1 สถานะจะเปลี่ยนเป็น "ได้รับการยอมรับบน L1" ตามที่แสดงในการทำธุรกรรมต่อไปนี้:

ข้อมูลการทำธุรกรรมถูกอัปโหลดไปยัง L1 แล้ว

แม้ว่าการทำธุรกรรมใน StarkNet จะมีชุดสถานะที่มีคุณภาพมากกว่าเพื่อแจ้งให้ผู้ใช้ทราบเกี่ยวกับความคืบหน้าในการประมวลผล การอัปโหลดธุรกรรมไปยัง L1 อาจยังต้องรอเป็นเวลาหลายชั่วโมง (อาจเป็นเพราะการสร้างพิสูจน์ที่เป็นศูนย์ใช้เวลานาน) ในระหว่างเวลานี้ผู้ใช้จึงอาศัยใน Pre-Confirmation ของ Sequencer

นอกจากนี้ Explorer แสดงเฉพาะ "ได้รับการยอมรับบน L1" สำหรับธุรกรรมที่อัปโหลดไปที่ L1 เท่านั้น โดยไม่มีข้อมูลช่วยเหลือเกี่ยวกับ L1 Finality หรือ Block Confirmation นี่หมายความว่าผู้ใช้ต้องตรวจสอบด้วยตนเองว่าบล็อก L1 มีบล็อกต่อมาเพียงพอหรือได้รับการ Finalized แล้วหรือยัง

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

สถานะรายได้จากรายการธุรกรรมของ zkSync

เหมือนกับ StakrNet, zkSync ยังมีสถานะ PENDING ซึ่งหมายความว่าโหนดได้รับธุรกรรมและไม่มีปัญหาหลังจากที่ธุรกรรมได้รับการยืนยันแล้ว มันจะรอให้รวมอยู่ในบล็อก L2 โดย Sequencer และถูกดำเนินการ อย่างไรก็ตาม ไม่มีธุรกรรมที่จะดำเนินการในสถานะ PENDING ผลลัพธ์

ผู้ใช้สามารถทราบความก้าวหน้าในการประมวลผลของธุรกรรมของตนผ่านสถานะการทำธุรกรรมที่แสดงบน zkSync Explorer

คำแนะนำในการอ่าน: หาก Sequencer ถูกประมวลผลอย่างรวดเร็วเพียงพอ อาจเป็นไปได้ที่จะข้ามสถานะ PENDING โดยตรงและเข้าสู่สถานะที่ธุรกรรมได้รับการประมวลผลแล้ว

สำหรับข้อมูลที่เป็นรายละเอียดมากขึ้นเกี่ยวกับขั้นตอนการทำธุรกรรมของ zkSync คุณสามารถคัดลอกลิงก์ด้านล่างและดูได้ในเบราว์เซอร์ของคุณ:https://era.zksync.io/docs/reference/concepts/finality.html#finality-on-ethereum

ธุรกรรมที่เห็นบน zkSync Explorer ยังรวมถึงธุรกรรมก่อนการยืนยัน เช่น ธุรกรรมในภาพหน้าจอด้านล่าง คุณสามารถเห็นว่าสถานะปัจจุบันคือ zkSync Era Processed ซึ่งบ่งชี้ว่าได้เข้าคิวเข้าไปในบล็อก L2 โดย Sequencer:

ธุรกรรมนี้ถูกจัดในบล็อก L2 โดย Sequencer และกำลังรอการอัปโหลดไปยัง L1 (Ethereum Sending)

หลังจากที่ตัวจัดเตรียม (Sequencer) ทำการเสร็จสิ้นบล็อก L2 แล้ว บล็อกและธุรกรรมที่อยู่ในบล็อกนั้นจะผ่านสามขั้นตอน คือ Committed, Proven และ Executed ตามลำดับ ซึ่งหมายถึง “บล็อกได้ถูกอัปโหลดไปยัง L1” และ “ความถูกต้องของบล็อกได้รับการพิสูจน์” และ “สถานะ L2 ถูกอัพเดตไปยัง L1 หลังจากที่ธุรกรรมในบล็อกถูกดำเนินการ” ต่อไปนี้แสดงบล็อกและธุรกรรมสามชุดที่อยู่ในขั้นตอนต่างๆ:

Batch 292700 ถูกอัปโหลดไปยัง L1 และเข้าสู่ขั้นตอน Committed แล้ว แหล่งที่มา: https://explorer.zksync.io/batch/292700

สถานะปัจจุบันของธุรกรรมในชุด 292700 ได้เปลี่ยนจากการส่ง Ethereum เป็นการตรวจสอบ Ethereum ซึ่งหมายถึงว่ากำลังรอการตรวจสอบโดยพิสูจน์ด้วยศักย์เพื่อยืนยันความถูกต้อง

การเลื่อนลูกศรเหนือไอคอน Ethereum Validating จะแสดงขั้นตอนที่แตกต่างกัน และลิงก์ธุรกรรมสำหรับขั้นตอนก่อนหน้า (การส่ง) ก็จะถูกแนบมาด้วย:

ธุรกรรมนี้ได้เข้าสู่ขั้นตอน "การตรวจสอบ" ลิงก์ธุรกรรมสำหรับการอัปโหลดแบทช์ไปยัง L1 ในขั้นตอนก่อนหน้า (การส่ง) ยังสามารถมองเห็นได้โดยตรงที่นี่

ความมีประสิทธิภาพของ Batch 292000 ได้รับการพิสูจน์แล้ว จึงเข้าสู่ขั้นตอนที่ได้รับการพิสูจน์:

หลังจากที่ Batch ได้รับการพิสูจน์แล้ว มันจะเข้าสู่สถานะที่ได้รับการพิสูจน์ และมีลิงก์ธุรกรรมสำหรับดำเนินการ Prove ที่แนบมา

ธุรกรรมภายในจะเข้าสู่ขั้นตอน "กำลังดำเนินการ" จาก "กำลังตรวจสอบ" ซึ่งกำลังรอการดำเนินการ

เมื่อ Batch ได้รับการพิสูจน์แล้ว จะเข้าสู่ช่วงรอ (เอกสารทางการระบุว่าประมาณ 21 ชั่วโมง) ก่อนที่จะดำเนินการธุรกรรมภายในและอัปเดตสถานะ L2 ที่บันทึกบน L1 นี่เป็นเนื่องจากมีมาตรการป้องกันที่ยังอยู่ในระยะ Alpha เพื่อให้มั่นใจว่ามีเวลาเพียงพอในการตอบสนองเมื่อเกิดข้อผิดพลาดใด ๆ เมื่อ Batch ถูกดำเนินการแล้ว จะเข้าสู่เฟส Executed สุดท้าย

หลังจาก Batch ถูกดำเนินการ เข้าสู่สถานะ Executed สุดท้าย และมีการแนบลิงก์ธุรกรรมสำหรับการดำเนินการ Execute

สถานะธุรกรรมในชุดจะถูกอัปเดตเป็น "ดําเนินการ" ด้วย ซึ่งแตกต่างจากธุรกรรม StarkNet ซึ่งเสร็จสมบูรณ์จาก Layer 2 (L2) ถึง Layer 1 (L1) ในขั้นตอนเดียว zkSync แบ่งกระบวนการทําธุรกรรมจาก L2 ถึง L1 ออกเป็นสามขั้นตอนโดยละเอียดเพิ่มเติม: มุ่งมั่น→พิสูจน์แล้ว→ดําเนินการ แม้ว่าสิ่งนี้จะยืดเวลากระบวนการทําธุรกรรมทั้งหมดออกไปประมาณหนึ่งวันเพื่อเป็นมาตรการป้องกัน แต่สถานะ Committed ช่วยให้ผู้ใช้ทราบได้อย่างรวดเร็วว่าธุรกรรมของพวกเขาถูกรวมไว้หรือไม่ (เมื่อธุรกรรมเข้าสู่ขั้นตอน Committed จะไม่ใช่แค่การยืนยันล่วงหน้าอีกต่อไป) โดยไม่ต้องพึ่งพาความไว้วางใจใน Sequencer อย่างต่อเนื่อง นอกจากนี้ zkSync Explorer ยังให้การแสดงข้อมูลที่ครอบคลุมและสมบูรณ์สําหรับขั้นตอนต่างๆทําให้ทุกคนสามารถเข้าใจสถานะล่าสุดของธุรกรรมและแม้แต่ตรวจสอบการดําเนินการของธุรกรรมในแต่ละขั้นตอน (เช่นจาก Committed to Proven จาก Proven to Executed) อย่างไรก็ตามสิ่งสําคัญคือต้องทราบว่าเพื่อเป็นมาตรการป้องกันในขั้นตอนอัลฟ่า zkSync Sequencer สามารถแก้ไขบันทึกทางประวัติศาสตร์ได้ สิ่งนี้บ่งชี้ว่าแม้ว่าธุรกรรมจะสามารถก้าวข้ามการยืนยันล่วงหน้าเพื่อเข้าสู่ขั้นตอน Committed ได้อย่างรวดเร็ว แต่ Sequencer ยังสามารถลบธุรกรรมของผู้ใช้ออกจากบันทึกประวัติได้จนกว่าจะถึงขั้นตอนการดําเนินการ ดังนั้นผู้ใช้ยังคงต้องไว้วางใจซีเควนเซอร์นานถึงหนึ่งวัน

Layer 1 ยังสามารถรองรับการยืนยันก่อน

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

ปรับปรุงก่อนการยืนยัน:

การยืนยันล่วงหน้าเป็นเพียงคํามั่นสัญญาด้วยวาจาโดย Builders หรือ L2 Sequencers โดยไม่มีข้อผูกมัดในการปฏิบัติตามสัญญาและไม่มีกลไกการลงโทษสําหรับการไม่ปฏิบัติตาม อย่างไรก็ตาม เป็นไปได้ที่จะทําให้คํามั่นสัญญานี้มีความน่าเชื่อถือมากขึ้นโดยใช้สัญญาอัจฉริยะเพื่อสร้างมาตรฐานให้กับผู้สร้างหรือซีเควนเซอร์ พวกเขาสามารถให้บริการยืนยันล่วงหน้าในขณะที่ยังฝากพันธบัตรในสัญญาอัจฉริยะและลงนามในเนื้อหาเมื่อทําสัญญารวมธุรกรรม หากผู้ใช้พบว่าผู้สร้างหรือซีเควนเซอร์ไม่ปฏิบัติตามสัญญาพวกเขาสามารถส่งเนื้อหาสัญญาและลายเซ็นไปยังสัญญาอัจฉริยะซึ่งสามารถตรวจสอบได้ว่าสัญญานั้นถูกเก็บไว้หรือไม่ แม้ว่าสถานการณ์การใช้งานของสัญญาดังกล่าวจะยังอยู่ในขั้นตอนการพิสูจน์แนวคิด แต่ลิงก์ด้านล่างจะแสดงวิดีโอการนําเสนอตัวอย่างการสมัครสัญญาดังกล่าว

สรุป:

หลังจากธุรกรรม L1 รวมอยู่ในบล็อก L1 ความน่าจะเป็นของการจัดระเบียบใหม่จะลดลงและความเชื่อมั่นของผู้ใช้ในการรวมธุรกรรมจะค่อยๆเพิ่มขึ้น ธุรกรรม L2 มีเวิร์กโฟลว์เพิ่มเติมเมื่อเทียบกับธุรกรรม L1: "ธุรกรรม L2 รวมอยู่ในบล็อก L2 และรอการอัปโหลดไปยัง L1" อย่างไรก็ตามเนื่องจากข้อมูลยังไม่ถูกอัปโหลดไปยัง L1 ในขั้นตอนนี้จึงมีความเป็นไปได้ที่จะเกิดความแปรปรวนดังนั้นการรับประกันผู้ใช้จะได้รับเกี่ยวกับการรวมธุรกรรมในขั้นตอนนี้คือความมุ่งมั่นด้วยวาจาจาก Sequencer หรือที่เรียกว่า Pre-Confirmation หรือ Fast Confirmation / Soft Confirmation หากซีเควนเซอร์เป็นอันตรายหรือพบข้อบกพร่องสัญญาของพวกเขาอาจถูกทําลายซึ่งนําไปสู่การขาดการยืนยันสําหรับธุรกรรม L2 ของผู้ใช้ ปัจจุบัน L2 ส่วนใหญ่แสดงสถานะธุรกรรมใน Explorers ซึ่งรวมถึงสถานะการยืนยันล่วงหน้า เช่น Arbitrum/Optimism's Confirmed by Sequencer หรือ StarkNet's Accepted on L2 เมื่อเห็นข้อมูลดังกล่าวสิ่งสําคัญคือต้องใส่ใจกับประสิทธิภาพของเวลาของการประกันการรวมธุรกรรมที่ให้ไว้ หากผู้ใช้ไม่ต้องการพึ่งพาการยืนยันล่วงหน้าของ Sequencer พวกเขาจะต้องรอนานขึ้นและตรวจสอบผ่านข้อมูลของ L2 Explorer เกี่ยวกับข้อมูล L2 ที่ถูกอัปโหลดไปยัง L1 การยืนยันล่วงหน้าสามารถรวมกลไกจูงใจทางเศรษฐกิจเช่นการลงโทษซีเควนเซอร์ผ่านสัญญาอัจฉริยะเมื่อพวกเขาผิดสัญญาทําให้ผู้ใช้ได้รับการปกป้องที่ชัดเจนยิ่งขึ้น ตารางด้านล่างแสดงการรับประกันการรวมธุรกรรมและสถานการณ์ความเสี่ยงที่สอดคล้องกันโดยธุรกรรม L1 และ L2 ในขั้นตอนต่างๆ ของกระบวนการทําธุรกรรม

ข้อปฏิเสธ：

1. บทความนี้ถูกพิมพ์ใหม่จาก [Gateaicoin]. ลิขสิทธิ์ทั้งหมดเป็นของผู้เขียนต้นฉบับ [ข่าวคาดการณ์]. หากมีข้อแก้และติดต่อGate Learnทีม และพวกเขาจะดำเนินการด้วยรวดเร็ว
2. คำปฏิเสธความรับผิด: มุมมองและความคิดเห็นที่แสดงในบทความนี้เป็นเพียงของผู้เขียนเท่านั้น และไม่ใช่คำแนะนำในการลงทุนใดๆ
3. การแปลบทความเป็นภาษาอื่นๆ ระหว่างทีม Gate Learn ดำเนินการ นอกจากนี้หากไม่ได้กล่าวถึง การคัดลอก การกระจายหรือการลอกเลียนแบบบทความที่ได้รับการแปลนั้นถือเป็นการละเมิดทรัพย์สินทางปัญญา