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

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

ความรู้พื้นฐานที่ต้องมี:

1. กระบวนการทั้งหมดของธุรกรรม L1 (ชั้นที่ 1)

2. สาเหตุและผลกระทบของ Re-orgs

3. เข้าใจบทบาทและวิธีการทำงานในสถาปัตยกรรม PBS ปัจจุบันของ Ethereum

4. เข้าใจความแตกต่างระหว่าง Optimistic Rollup และ Validity (ZK) Rollup

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

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

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

ขั้นตอนการทำธุรกรรม L1 อธิบายกระบวนการ

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

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

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

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

หลังจากที่ผู้ใช้ L2 สร้างและลงนามในธุรกรรมโดยทั่วไปจะถูกส่งไปยังซีเควนเซอร์ที่รับผิดชอบในการสั่งซื้อธุรกรรมโดยตรง จากนั้นซีเควนเซอร์จะรวมธุรกรรมนี้ไว้ในบล็อก 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 รับรองกับผู้ใช้เมื่อได้รับธุรกรรมว่าจะถูกรวมไว้ทันทีหรือในบล็อก Xth การรับรองนี้อาจเพียงพอสําหรับผู้ที่ต้องการไว้วางใจ Sequencer สิ่งนี้คล้ายกับผู้ใช้ที่ไว้วางใจแอปกระเป๋าเงินของพวกเขาที่ไม่ได้ตรวจสอบ Etherscan ซ้ํา ๆ เพื่อยืนยันการทําธุรกรรมหลังจากที่กระเป๋าเงินได้แจ้งให้พวกเขาทราบถึงการรวม

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

ต่อไปเราจะแนะนำวิธีการหลากหลายวิธีในการแสดงสถานะของการรวมธุรกรรม L2

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

ปัจจุบันหลังจากที่ผู้ใช้ส่งธุรกรรมบน 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

ธุรกรรมที่แสดงบน Arbitrum Explorer รวมถึงธุรกรรมที่มี Pre-Confirmation คือ ธุรกรรมที่ยังไม่ได้อัปโหลดไปยัง L1 ตามที่แสดงในภาพต่อไปนี้ ธุรกรรมที่มี Block Number 145353000 ถูกทำเครื่องหมายว่า "Confirmed by Sequencer" ซึ่งหมายถึงว่าได้รับการยืนยันจาก Sequencer แต่ยังไม่ได้อัปโหลดไปยัง L1:

[Image shows a transaction confirmed by Sequencer but not uploaded to L1]

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

[Image shows a transaction on L1 with 69 block confirmations]

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

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

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

การทำธุรกรรมที่แสดงบน Optimism Explorer รวมถึงการทำธุรกรรมที่มี Pre-Confirmation หรือการทำธุรกรรมที่ยังไม่ได้อัปโหลดไปยัง L1 ดังที่แสดงในภาพต่อไปนี้ การทำธุรกรรมด้วยหมายเลขบล็อก 111526300 ถูกทำเครื่องหมายว่า “ได้รับยืนยันโดย Sequencer”

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

อย่างไรก็ตาม Explorer ไม่ได้กําหนดความหมายของ "ยืนยันโดย Sequencer อย่างชัดเจน" ระบุว่า "การยืนยันซีเควนเซอร์เทียบเท่ากับการยืนยันบล็อกสองสามรายการใน L1" ซึ่งชี้ให้เห็นว่าธุรกรรมที่ทําเครื่องหมายว่า "ยืนยันโดย Sequencer" ได้รับการอัปโหลดไปยัง L1 และมีหลายบล็อกดังต่อไปนี้:

[Image shows ธุรกรรมล่าสุดที่ถูกทำเครื่องหมายว่า "ได้รับการยืนยันโดยผู้เรียงลำดับ"]

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

แสดงรายการธุรกรรมจากวันก่อนหน้ายังคงถูกทำเครื่องหมายว่า "ยืนยันโดย Sequencer"

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

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

[Image shows a transaction with L1 State Batch information]

การคลิกที่ State Batch "3480" จะแสดงสถานะของมันว่าเป็น Finalized สถานะ Finalized นี้สอดคล้องกับ mainnet ของ Ethereum และหมายถึงสถานะที่มีความปลอดภัยมากมีสำเร็จการสะสมโหวตจาก validator ได้สอง epochs

[Image shows State Batch 3480 finalized in L1 Block 18457449]

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

หากมีการอัปโหลดชุดข้อมูล แต่ยังไม่ได้สรุปบน L1 จะแสดงเป็น ยังไม่ได้สรุป:

[ภาพแสดงการอัปโหลดชุดรัฐบาลไปที่ L1 แต่ยังไม่ได้สิ้นสุด]

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

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

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

หมายเหตุ: หากตัวจัดเตรียมประมวลกิจกรรมสามารถทำการประมวลผลธุรกรรมอย่างรวดเร็วเพียงพอ อาจข้ามสถานะที่ได้รับและย้ายไปที่สถานะที่ถูกประมวลผลโดยตรง สำหรับข้อมูลเพิ่มเติมเกี่ยวกับกระบวนการธุรกรรมของ StarkNet โปรดอ้างถึงเอกสารทางการที่https://docs.starknet.io/documentation/architecture_and_concepts/Network_Architecture/transaction-life-cycle/

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

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

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

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

รายการที่กำลังดำเนินการโดย Sequencer

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

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

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

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

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

สถานะการรวมธุรกรรม zkSync

เช่นเดียวกับ StarkNet zkSync ยังมีสถานะรอดําเนินการซึ่งบ่งชี้ว่าโหนดได้รับและตรวจสอบธุรกรรมโดยไม่มีปัญหาใด ๆ จากนั้นธุรกรรมจะรอการรวมและดําเนินการในบล็อก L2 โดย Sequencer ธุรกรรมในสถานะรอดําเนินการยังไม่มีผลการดําเนินการใดๆ

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

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

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

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

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

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

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

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

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

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

Batch 292000 ได้รับการพิสูจน์ถูกต้อง ดังนั้นจึงเข้าสู่ขั้นตอน Proven:

หลังจากที่ชุดถูกพิสูจน์แล้ว มันจะเข้าสู่สถานะที่ถูกพิสูจน์ พร้อมลิงก์ไปยังการดำเนินการทำให้เป็นจริง

ธุรกรรมจะเปลี่ยนจาก "การตรวจสอบ" เป็น "การดำเนินการ" ซึ่งหมายความว่าพวกเขากำลังรอการดำเนินการ

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

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

สถานะของธุรกรรมในแบทช์ยังได้รับการอัปเดตเป็น "ดำเนินการ" ด้วย

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

อย่างไรก็ตาม สิ่งสำคัญที่ต้องระบุไว้ไว้เป็นว่าเป็นมาตรการการป้องกันในช่วง Alpha ซึ่ง zkSync Sequencer ในปัจจุบันสามารถแก้ไขบันทึกประวัติได้ ซึ่งหมายความว่า แม้ว่าธุรกรรมจะสามารถย้ายออกจากสถานะ Pre-Confirmation เข้าสู่ขั้นตอน Committed ได้อย่างรวดเร็ว แต่ Sequencer ยังคงสามารถลบธุรกรรมของผู้ใช้ออกจากบันทึกประวัติได้จนกระทั่งว่าพวกเขาจะเข้าสู่ขั้นตอน Executed ดังนั้น ผู้ใช้ยังต้องเชื่อใจ Sequencer อย่างน้อยถึง 1 วัน

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

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

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

เคล็ดลับการอ่าน: สำหรับข้อมูลเพิ่มเติมเกี่ยวกับ PBS โปรดคัดลอกลิงก์ด้านล่างไปยังเบราว์เซอร์ของคุณเพื่ออ่าน:https://mirror.xyz/0x347c9872A2a1dE370D798f9FE96341A9A0E05af8/oG_4j_-TweXHX_LMag656k_pAyJWIBXpEDrzpUfVsss.

การปรับปรุงการยืนยันล่วงหน้า

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

แม้ว่าการใช้สัญญาดังกล่าวจะยังอยู่ในขั้นตอนการพิสูจน์แนวคิด แต่ลิงก์ต่อไปนี้ไปยังวิดีโอการนําเสนอจะแสดงตัวอย่างหนึ่งของการสมัครสัญญา:

https://www.youtube.com/watch?v=Uw5HxSYXwYo

สรุป

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

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

ถ้าตัวควบคุมมีความทรมานหรือเผชิญกับบั๊ก การสัญญาของพวกเขาอาจถูกแตก ซึ่งอาจทำให้ไม่มีการยืนยันสำหรับธุรกรรม L2 ของผู้ใช้ได้

ในปัจจุบัน เหล่า L2 ส่วนใหญ่จะแสดงสถานะการทำธุรกรรมในตัวสำรวจของพวกเขา รวมถึงสถานะก่อนการยืนยัน เช่น "Confirmed by Sequencer" ของ Arbitrum/Optimism หรือ "Accepted on L2" ของ StarkNet ผู้ใช้ควรทราบถึงความถูกต้องในเวลาของการให้ความมั่นใจในการรวมธุรกรรมที่ได้รับจากสถานะเหล่านี้

หากผู้ใช้ไม่ต้องการไว้วางใจ Pre-Confirmation ของ Sequencer พวกเขาจะต้องรอนานขึ้นและตรวจสอบผ่านข้อมูลที่ L2 Explorer ให้เกี่ยวกับข้อมูล L2 ที่ถูกอัปโหลดไปยัง L1

การยืนยันล่วงหน้าอาจรวมถึงกลไกจูงใจทางเศรษฐกิจเช่นบทลงโทษผ่านสัญญาอัจฉริยะสําหรับซีเควนเซอร์ที่ละเมิดสัญญาโดยให้ความคุ้มครองที่ชัดเจนยิ่งขึ้นแก่ผู้ใช้

ตารางด้านล่างแสดงการรับรองการรวมรายการธุรกรรมและสถานการณ์ความเสี่ยงที่เกี่ยวข้องสำหรับขั้นตอนต่าง ๆ ของธุรกรรม L1 และ L2: [โปรดทราบว่าตารางไม่ได้ระบุในการแปลเป็นภาษาไทย]

Disclaimer：

1. บทความนี้ถูกพิมพ์ซ้ำจาก [ imToken Labs]. ลิขสิทธิ์ทั้งหมดเป็นของผู้เขียนต้นฉบับ [Nic]. If there are objections to this reprint, please contact the Gate Learnทีม และพวกเขาจะดำเนินการโดยเร็ว
2. คำปฏิเสธความรับผิด: มุมมองและความคิดเห็นที่แสดงในบทความนี้เป็นเพียงของผู้เขียนเท่านั้น และไม่เป็นการให้คำแนะนำทางการลงทุนใดๆ
3. การแปลบทความเป็นภาษาอื่นๆ ดำเนินการโดยทีม Gate Learn หากไม่ได้กล่าวถึง การคัดลอก การกระจาย หรือการลอกเลียนแบบบทความที่ถูกแปลนั้นถือเป็นการละเมิดลิขสิทธิ์