เส้นทางของ BNB Chain สู่บล็อกใหญ่

ถนนแห่งบล็อกใหญ่บน BNB Chain

เช่นเดียวกับ Solana, Heco และเครือข่ายสาธารณะอื่นๆ ที่ได้รับการสนับสนุนจากการแลกเปลี่ยน เครือข่ายสาธารณะ BNB Smart Chain (BSC) ของ BNB Chain ก็ได้ดำเนินการในระดับสูงมายาวนาน นับตั้งแต่เปิดตัวในปี 2563 BSC ได้กำหนดขีดจำกัดกำลังการผลิตก๊าซสำหรับแต่ละบล็อกไว้ที่ 30 ล้านบล็อก โดยมีช่วงเวลาบล็อกคงที่ที่ 3 วินาที ด้วยพารามิเตอร์ดังกล่าว BSC บรรลุ TPS สูงสุด (TPS ที่มีธุรกรรมต่างๆ ผสมกัน) มากกว่า 100 ในเดือนมิถุนายน 2564 ขีดจำกัดก๊าซบล็อกของ BSC เพิ่มขึ้นเป็น 60 ล้าน อย่างไรก็ตาม ในเดือนกรกฎาคมของปีเดียวกัน เกมลูกโซ่ที่เรียกว่า CryptoBlades ได้ระเบิดบน BSC ส่งผลให้ปริมาณธุรกรรมรายวันเกิน 8 ล้านรายการ และส่งผลให้ค่าธรรมเนียมพุ่งสูงขึ้น ปรากฎว่าจุดคอขวดด้านประสิทธิภาพของ BSC ยังค่อนข้างชัดเจนในขณะนั้น

(ที่มา: BscScan)

เพื่อแก้ไขปัญหาประสิทธิภาพของเครือข่าย BSC ได้เพิ่มขีดจำกัดก๊าซสำหรับแต่ละบล็อกอีกครั้ง ซึ่งยังคงที่ประมาณ 80-85 ล้านมาเป็นเวลานาน ในเดือนกันยายน 2022 ขีดจำกัดการใช้ก๊าซต่อบล็อกของ BSC Chain เพิ่มขึ้นเป็น 120 ล้าน และภายในสิ้นปีนี้ ก็เพิ่มเป็น 140 ล้าน เกือบห้าเท่าของปี 2020 ก่อนหน้านี้ BSC ได้วางแผนที่จะเพิ่มขีดจำกัดความจุก๊าซบล็อกเป็น 300 ล้าน แต่บางทีเมื่อพิจารณาถึงภาระหนักบนโหนด Validator ข้อเสนอสำหรับบล็อกขนาดใหญ่พิเศษดังกล่าวยังไม่ได้ถูกนำมาใช้

ที่มา: YCHARTS

ต่อมา BNB Chain ดูเหมือนจะมุ่งเน้นไปที่แทร็กแบบโมดูลาร์/เลเยอร์ 2 มากกว่าที่จะคงอยู่ในการขยายเลเยอร์ 1 ความตั้งใจนี้ชัดเจนมากขึ้นจากการเปิดตัว zkBNB ในช่วงครึ่งหลังของปีที่แล้วสู่ GreenField เมื่อต้นปีนี้ จากความสนใจอย่างมากในบล็อกเชนแบบแยกส่วน/เลเยอร์2 ผู้เขียนบทความนี้จะใช้ opBNB เป็นวัตถุวิจัยเพื่อเปิดเผยจุดคอขวดด้านประสิทธิภาพของ Rollup โดยการเปรียบเทียบกับ Ethereum Layer2

การเพิ่มปริมาณงานที่สูงของ BSC ไปยังเลเยอร์ DA ของ opBNB

ดังที่เราทุกคนทราบ Celestia ได้สรุปองค์ประกอบสำคัญสี่ประการตามขั้นตอนการทำงานของบล็อกเชนแบบโมดูลาร์: Execution Layer: ดำเนินการรหัสสัญญาและดำเนินการเปลี่ยนสถานะให้เสร็จสมบูรณ์ Settlement Layer: จัดการหลักฐานการฉ้อโกง/หลักฐานความถูกต้อง และแก้ไขปัญหาการเชื่อมโยงระหว่าง L2 และ L1 ฉันทามติเลเยอร์: บรรลุฉันทามติในการสั่งซื้อธุรกรรม Data Availability Layer (DA): เผยแพร่ข้อมูลที่เกี่ยวข้องกับบัญชีแยกประเภทบล็อคเชน ช่วยให้ผู้ตรวจสอบสามารถดาวน์โหลดข้อมูลนี้ได้

ในหมู่พวกเขา ชั้น DA มักจะอยู่ควบคู่กับชั้นฉันทามติ ตัวอย่างเช่น ข้อมูลของ DA ของ Optimistic Rollup มีชุดลำดับธุรกรรมในบล็อก L2 เมื่อโหนดเต็ม L2 ได้รับข้อมูล DA โหนดจะรู้ลำดับของแต่ละธุรกรรมในชุดนี้ (ด้วยเหตุผลนี้ ชุมชน Ethereum จึงเชื่อว่าเลเยอร์ DA และเลเยอร์ฉันทามติมีความเกี่ยวข้องกันเมื่อทำเลเยอร์ Rollup)

อย่างไรก็ตาม สำหรับ Ethereum Layer2 ปริมาณงานข้อมูลของเลเยอร์ DA (Ethereum) ได้กลายเป็นคอขวดที่ใหญ่ที่สุดที่จำกัดประสิทธิภาพ Rollup เนื่องจากปริมาณการรับส่งข้อมูลปัจจุบันของ Ethereum ต่ำเกินไป บังคับให้ Rollup ต้องระงับ TPS ของตนให้มากที่สุดเท่าที่จะเป็นไปได้เพื่อป้องกันไม่ให้ Ethereum mainnet ไม่สามารถรับข้อมูลที่สร้างโดย L2 ได้ ในเวลาเดียวกัน ปริมาณข้อมูลต่ำทำให้คำสั่งธุรกรรมจำนวนมากภายในเครือข่าย Ethereum อยู่ในสถานะรอดำเนินการ ส่งผลให้ค่าธรรมเนียมก๊าซถูกผลักดันไปสู่ระดับที่สูงมาก และทำให้ต้นทุนการเผยแพร่ข้อมูลสำหรับเลเยอร์ 2 เพิ่มขึ้นอีก ในที่สุด เครือข่าย Layer2 จำนวนมากต้องใช้เลเยอร์ DA ภายนอก Ethereum เช่น Celestia และ opBNB ซึ่งอยู่ใกล้กับแหล่งน้ำ ได้เลือกที่จะใช้ BSC ที่มีปริมาณงานสูงโดยตรงเพื่อใช้ DA เพื่อแก้ไขปัญหาคอขวดของการเผยแพร่ข้อมูล เพื่อความสะดวกในการทำความเข้าใจ ขอแนะนำวิธีการเผยแพร่ข้อมูล DA สำหรับ Rollup กัน ยกตัวอย่าง Arbitrum เชน Ethereum ที่ควบคุมโดยที่อยู่ EOA ของซีเควนเซอร์ Layer2 จะส่งธุรกรรมเป็นระยะไปยังสัญญาที่ระบุ ใน calldata ของพารามิเตอร์อินพุตของคำสั่งนี้ ข้อมูลธุรกรรมแบบแพ็กเกจจะถูกเขียน และเหตุการณ์ออนไลน์ที่เกี่ยวข้องจะถูกทริกเกอร์ โดยทิ้งบันทึกถาวรไว้ในบันทึกสัญญา

ด้วยวิธีนี้ข้อมูลธุรกรรมของ Layer2 จะถูกจัดเก็บไว้ในบล็อก Ethereum เป็นเวลานาน ผู้ที่สามารถใช้งานโหนด L2 ได้สามารถดาวน์โหลดบันทึกที่เกี่ยวข้องและแยกวิเคราะห์ข้อมูลที่เกี่ยวข้องได้ แต่โหนด Ethereum เองจะไม่ดำเนินการธุรกรรม L2 เหล่านี้ เป็นเรื่องง่ายที่จะเห็นว่า L2 เก็บข้อมูลธุรกรรมไว้ในบล็อก Ethereum เท่านั้น ซึ่งทำให้เกิดต้นทุนการจัดเก็บข้อมูล ในขณะที่ต้นทุนการคำนวณในการดำเนินการธุรกรรมจะตกเป็นภาระของโหนด L2 เอง ที่กล่าวมาข้างต้นเป็นวิธีการดำเนินการตาม DA ของ Arbitrum ในขณะที่ Optimism ใช้ที่อยู่ EOA ที่ควบคุมโดยตัวจัดลำดับเพื่อถ่ายโอนไปยังที่อยู่ EOA ที่ระบุอื่น โดยนำข้อมูลธุรกรรม Layer2 ชุดใหม่ในข้อมูลเพิ่มเติม สำหรับ opBNB ซึ่งใช้ OP Stack นั้น วิธีการเผยแพร่ข้อมูล DA นั้นโดยพื้นฐานแล้วจะเหมือนกับวิธีการมองโลกในแง่ดี

เห็นได้ชัดว่าปริมาณการประมวลผลของเลเยอร์ DA จะจำกัดขนาดของข้อมูลที่ Rollup สามารถเผยแพร่ได้ในหน่วยเวลา ดังนั้นจึงเป็นการจำกัด TPS เมื่อพิจารณาว่าหลังจาก EIP1559 ความจุก๊าซของแต่ละบล็อก ETH จะคงที่ที่ 30 ล้าน และเวลาในการบล็อกหลังจากการรวมอยู่ที่ประมาณ 12 วินาที Ethereum สามารถรองรับก๊าซได้สูงสุดเพียง 2.5 ล้านต่อวินาที โดยส่วนใหญ่ ปริมาณการใช้โดยรองรับข้อมูลธุรกรรม L2 ต่อไบต์ใน calldata คือ 16 ดังนั้น Ethereum จึงสามารถรองรับขนาด calldata สูงสุดเพียง 150 KB ต่อวินาที ในทางตรงกันข้าม ขนาดข้อมูลการโทรเฉลี่ยสูงสุดของ BSC ที่ประมวลผลต่อวินาทีคือประมาณ 2910 KB ซึ่งมากกว่า Ethereum 18.6 เท่า ความแตกต่างระหว่างทั้งสองในฐานะเลเยอร์ DA นั้นชัดเจน

โดยสรุป Ethereum สามารถรองรับข้อมูลธุรกรรม L2 ได้ประมาณ 150 KB ต่อวินาที แม้หลังจากเปิดตัว EIP 4844 แล้ว ตัวเลขนี้ก็จะไม่เปลี่ยนแปลงมากนัก เพียงแต่ลดค่าธรรมเนียม DA เท่านั้น แล้วข้อมูลธุรกรรมสามารถรวมไว้ในประมาณ 150KB ต่อวินาทีได้อย่างไร ที่นี่เราต้องอธิบายอัตราการบีบอัดข้อมูลของ Rollup Vitalik มองโลกในแง่ดีมากเกินไปในปี 2021 โดยประเมินว่า Optimistic Rollup สามารถบีบอัดขนาดข้อมูลธุรกรรมให้เป็น 11% ของขนาดดั้งเดิมได้ ตัวอย่างเช่น การถ่ายโอน ETH พื้นฐาน ซึ่งเดิมมีขนาด calldata 112 ไบต์ สามารถบีบอัดได้ถึง 12 ไบต์โดย Optimistic Rollup การถ่ายโอน ERC-20 สามารถบีบอัดได้ถึง 16 ไบต์ และธุรกรรม Swap บน Uniswap สามารถบีบอัดได้ถึง 14 ไบต์ ตามการประมาณการของเขา Ethereum สามารถบันทึกธุรกรรมได้ประมาณ 10,000 L2 ต่อวินาที (โดยมีหลายประเภทผสมกัน) อย่างไรก็ตาม จากข้อมูลที่เปิดเผยโดยทีมงาน Optimism ในปี 2565 อัตราการบีบอัดข้อมูลจริงอาจสูงถึงสูงสุดเพียงประมาณ 37% เท่านั้น ซึ่งต่ำกว่าประมาณการของ Vitalik ถึง 3.5 เท่า

(การประมาณค่าของ Vitalik เกี่ยวกับเอฟเฟกต์ความสามารถในการปรับขนาด Rollup นั้นเบี่ยงเบนไปจากเงื่อนไขจริงอย่างมาก)

(อัตราการบีบอัดจริงที่ได้จากอัลกอริธึมการบีบอัดต่างๆ ที่เปิดเผยโดย Optimism)

ลองให้ตัวเลขที่สมเหตุสมผล: แม้ว่า Ethereum จะถึงขีดจำกัดปริมาณงานแล้ว แต่ TPS สูงสุดของ Optimistic Rollups ทั้งหมดรวมกันนั้นมากกว่า 2000 เพียงเล็กน้อยเท่านั้น กล่าวอีกนัยหนึ่ง หากบล็อก Ethereum ถูกนำมาใช้ทั้งหมดเพื่อส่งข้อมูลที่เผยแพร่โดย Optimistic Rollups เช่นที่กระจายระหว่าง Arbitrum, Optimism, Base และ Boba TPS ที่รวมกันของ Optimistic Rollups เหล่านี้จะไม่ถึง 3000 ด้วยซ้ำ แม้จะต่ำกว่าระดับสูงสุดก็ตาม อัลกอริธึมการบีบอัดที่มีประสิทธิภาพ นอกจากนี้ เราต้องพิจารณาว่าหลังจาก EIP1559 ความจุก๊าซของแต่ละบล็อกจะมีค่าเฉลี่ยเพียง 50% ของค่าสูงสุด ดังนั้นตัวเลขข้างต้นจึงควรลดลงครึ่งหนึ่ง หลังจากการเปิดตัว EIP4844 แม้ว่าค่าธรรมเนียมการทำธุรกรรมสำหรับการเผยแพร่ข้อมูลจะลดลงอย่างมาก แต่ขนาดบล็อกสูงสุดของ Ethereum จะไม่เปลี่ยนแปลงมากนัก (เนื่องจากการเปลี่ยนแปลงมากเกินไปจะส่งผลต่อความปลอดภัยของห่วงโซ่หลัก ETH) ดังนั้นค่าประมาณข้างต้นจะไม่คืบหน้า มาก.

ตามข้อมูลจาก Arbiscan และ Etherscan ชุดธุรกรรมบน Arbitrum ประกอบด้วยธุรกรรม 1,115 รายการ ซึ่งใช้ก๊าซ 1.81 ล้านรายการบน Ethereum จากการประมาณค่า หากชั้น DA ถูกเติมลงในทุกบล็อก ขีดจำกัด TPS ตามทฤษฎีของ Arbitrum จะอยู่ที่ประมาณ 1,500 แน่นอนว่า เมื่อพิจารณาถึงปัญหาของการปรับโครงสร้างบล็อก L1 แล้ว Arbitrum ไม่สามารถเผยแพร่ชุดธุรกรรมในทุกบล็อก Ethereum ได้ ดังนั้นตัวเลขข้างต้นจึงเป็นเพียงตัวเลขทางทฤษฎีเท่านั้น นอกจากนี้ ด้วยการนำกระเป๋าสตางค์อัจฉริยะที่เกี่ยวข้องกับ EIP 4337 มาใช้อย่างแพร่หลาย ปัญหา DA จะรุนแรงยิ่งขึ้น เนื่องจากด้วยการรองรับ EIP 4337 ผู้ใช้จึงสามารถปรับแต่งวิธีที่ผู้ใช้ยืนยันตัวตนของตนได้ เช่น การอัปโหลดข้อมูลไบนารี่ของลายนิ้วมือหรือม่านตา ซึ่งจะเพิ่มขนาดข้อมูลที่ครอบครองโดยการทำธุรกรรมปกติ ดังนั้นปริมาณข้อมูลที่ต่ำของ Ethereum จึงเป็นคอขวดที่ใหญ่ที่สุดที่จำกัดประสิทธิภาพ Rollup และปัญหานี้อาจไม่ได้รับการแก้ไขอย่างเหมาะสมเป็นเวลานาน ในทางกลับกัน ใน BNB Chain ของเครือข่ายสาธารณะ BSC ขนาดข้อมูลการโทรเฉลี่ยสูงสุดที่ประมวลผลต่อวินาทีจะอยู่ที่ประมาณ 2910 KB ซึ่งมากกว่า Ethereum 18.6 เท่า กล่าวอีกนัยหนึ่ง ตราบใดที่เลเยอร์การดำเนินการสามารถรักษาไว้ได้ ขีดจำกัดบนของ TPS ตามทฤษฎีของเลเยอร์ 2 ภายในระบบนิเวศของ BNB Chain สามารถเข้าถึงได้ประมาณ 18 เท่าของ ARB หรือ OP ตัวเลขนี้คำนวณจากความจุบล็อกก๊าซสูงสุดของ BNB Chain ในปัจจุบันที่ 140 ล้าน โดยมีเวลาบล็อก 3 วินาที

กล่าวอีกนัยหนึ่ง ขีดจำกัด TPS รวมในปัจจุบันของ Rollups ทั้งหมดภายในระบบนิเวศ BNB Chain คือ 18.6 เท่าของ Ethereum (แม้ว่าจะพิจารณา ZKRollup ก็ตาม) จากมุมมองนี้ มันง่ายที่จะเข้าใจว่าทำไมโปรเจ็กต์ Layer2 จำนวนมากจึงใช้เลเยอร์ DA ภายใต้เชน Ethereum เพื่อเผยแพร่ข้อมูล เนื่องจากความแตกต่างค่อนข้างชัดเจน อย่างไรก็ตาม ปัญหาไม่ได้ง่ายนัก นอกจากปัญหาการรับส่งข้อมูลแล้ว ความเสถียรของ Layer1 เองก็สามารถส่งผลกระทบต่อ Layer2 ได้เช่นกัน ตัวอย่างเช่น Rollups ส่วนใหญ่มักจะรอเป็นเวลาหลายนาทีก่อนที่จะเผยแพร่ชุดธุรกรรมไปยัง Ethereum โดยพิจารณาถึงความเป็นไปได้ของการจัดโครงสร้างบล็อก Layer1 ใหม่ หากมีการจัดระเบียบบล็อก Layer1 ใหม่ มันจะส่งผลกระทบต่อบัญชีแยกประเภท blockchain ของ Layer2 ดังนั้น ตัวจัดลำดับจะรอให้บล็อก Layer1 ใหม่หลายบล็อกได้รับการเผยแพร่หลังจากแต่ละชุดธุรกรรม L2 ออก ซึ่งช่วยลดความน่าจะเป็นของการย้อนกลับบล็อกได้อย่างมาก ก่อนที่จะเผยแพร่ชุดธุรกรรม L2 ถัดไป สิ่งนี้จะทำให้เวลาที่บล็อก L2 ได้รับการยืนยันในที่สุด ทำให้ความเร็วในการยืนยันธุรกรรมขนาดใหญ่ลดลง (ธุรกรรมขนาดใหญ่ต้องการผลลัพธ์ที่ไม่สามารถย้อนกลับได้เพื่อความปลอดภัย) โดยสรุป ธุรกรรมที่เกิดขึ้นใน L2 จะไม่สามารถย้อนกลับได้หลังจากที่เผยแพร่ในบล็อกเลเยอร์ DA และหลังจากที่เลเยอร์ DA ได้สร้างบล็อกใหม่ตามจำนวนที่กำหนดแล้วเท่านั้น นี่เป็นเหตุผลสำคัญที่จำกัดประสิทธิภาพของชุดรวมอัปเดต อย่างไรก็ตาม Ethereum มีความเร็วในการสร้างบล็อกที่ช้า โดยใช้เวลา 12 วินาทีในการสร้างบล็อก สมมติว่า Rollup เผยแพร่ชุดของธุรกรรม L2 ทุกๆ 15 บล็อก จะมีช่วงเวลา 3 นาทีระหว่างชุดต่างๆ และหลังจากเผยแพร่แต่ละชุดแล้ว ยังคงต้องรอให้มีการสร้างบล็อก Layer1 หลายบล็อกก่อนที่จะเปลี่ยนกลับไม่ได้ (สมมติว่า ไม่ท้าทาย) แน่นอนว่าเวลาตั้งแต่เริ่มต้นจนถึงไม่สามารถย้อนกลับได้ของธุรกรรมบน Ethereum's Layer2 นั้นค่อนข้างนาน ส่งผลให้ความเร็วในการชำระหนี้ช้าลง ในขณะที่ BNB Chain ใช้เวลาเพียง 3 วินาทีในการสร้างบล็อก และบล็อกจะไม่สามารถย้อนกลับได้ในเวลาเพียง 45 วินาที (เวลาที่ใช้ในการสร้างบล็อกใหม่ 15 บล็อก) จากพารามิเตอร์ปัจจุบัน สมมติว่าจำนวนธุรกรรม L2 เท่ากัน และเมื่อพิจารณาถึงความสามารถในการย้อนกลับไม่ได้ของบล็อก L1 จำนวนครั้งที่ opBNB สามารถเผยแพร่ข้อมูลธุรกรรมในหน่วยเวลาสามารถสูงถึง 8.53 เท่าของ Arbitrum (หนึ่งครั้งทุกๆ 45 วินาทีสำหรับ อย่างแรกและทุกๆ 6.4 นาทีสำหรับอย่างหลัง) เห็นได้ชัดว่าความเร็วในการชำระธุรกรรมขนาดใหญ่บน opBNB นั้นเร็วกว่าบน Layer2 ของ Ethereum มาก นอกจากนี้ ขนาดข้อมูลสูงสุดที่เผยแพร่โดย opBNB ในแต่ละครั้งสามารถเข้าถึงได้ถึง 4.66 เท่าของ Layer2 ของ Ethereum (ขีดจำกัด L1 block gas ของเดิมคือ 140 ล้าน ในขณะที่ขนาดหลังคือ 30 ล้าน) 8.53 * 4.66 = 39.74 สิ่งนี้แสดงถึงช่องว่างระหว่าง opBNB และ Arbitrum ในแง่ของขีดจำกัด TPS ในการใช้งานจริง (ในปัจจุบัน ด้วยเหตุผลด้านความปลอดภัย ARB ดูเหมือนว่าจะลด TPS อย่างแข็งขัน แต่ในทางทฤษฎี หากเพิ่ม TPS ก็จะยังคงต่ำกว่าหลายเท่าเมื่อเทียบกับ opBNB ).

(ตัวจัดลำดับของ Arbitrum จะเผยแพร่ชุดธุรกรรมทุกๆ 6-7 นาที)

(ตัวจัดลำดับของ opBNB จะเผยแพร่ชุดธุรกรรมทุกๆ 1-2 นาที โดยเร็วที่สุดใช้เวลาเพียง 45 วินาที) แน่นอนว่ายังมีอีกประเด็นสำคัญที่ต้องพิจารณา ซึ่งก็คือค่าธรรมเนียมก๊าซในชั้น DA แต่ละครั้งที่ L2 เผยแพร่ชุดธุรกรรม จะมีต้นทุนคงที่ 21,000 Gas ที่ไม่เกี่ยวข้องกับขนาดข้อมูลการโทร ซึ่งเป็นค่าใช้จ่าย หากค่าธรรมเนียมก๊าซสำหรับเลเยอร์ DA/L1 สูง ส่งผลให้ต้นทุนคงที่ในการเผยแพร่ชุดธุรกรรมบน L2 ยังคงสูงอยู่ ตัวจัดลำดับจะลดความถี่ในการเผยแพร่ชุดธุรกรรม นอกจากนี้ เมื่อพิจารณาองค์ประกอบของค่าธรรมเนียม L2 ต้นทุนของเลเยอร์การดำเนินการจะต่ำมากและมักจะถูกละเลย โดยมุ่งเน้นเฉพาะผลกระทบของต้นทุน DA ต่อค่าธรรมเนียมการทำธุรกรรม โดยสรุป แม้ว่าการเผยแพร่ข้อมูลการโทรที่มีขนาดเท่ากันจะใช้ปริมาณก๊าซเท่ากันบน Ethereum และ BNB Chain แต่ราคาก๊าซที่เรียกเก็บโดย Ethereum นั้นสูงกว่าราคาของ BNB Chain ประมาณ 10 ถึงหลายสิบเท่า เมื่อแปลเป็นค่าธรรมเนียมการทำธุรกรรม L2 แล้ว ค่าธรรมเนียมการทำธุรกรรมของผู้ใช้ปัจจุบันบน Ethereum Layer2 ก็สูงกว่าค่าธรรมเนียมใน opBNB ประมาณ 10 ถึงหลายสิบเท่า โดยรวมแล้ว ความแตกต่างระหว่าง opBNB และ Optimistic Rollup บน Ethereum นั้นค่อนข้างชัดเจน

(ธุรกรรมที่ใช้ก๊าซ 150,000 หน่วยในการมองโลกในแง่ดีมีค่าใช้จ่าย 0.21 ดอลลาร์)

(ธุรกรรมที่ใช้ก๊าซ 130,000 รายการบน opBNB มีค่าใช้จ่าย 0.004 ดอลลาร์) อย่างไรก็ตาม การเพิ่มปริมาณงานข้อมูลของเลเยอร์ DA แม้ว่าจะสามารถเพิ่มปริมาณงานโดยรวมของระบบ Layer2 ได้ แต่ก็ยังส่งผลกระทบจำกัดต่อการปรับปรุงประสิทธิภาพของชุดรวมอัปเดตแต่ละรายการ เนื่องจากชั้นการดำเนินการมักจะประมวลผลธุรกรรมไม่เร็วพอ แม้ว่าจะสามารถละเว้นข้อจำกัดของเลเยอร์ DA ได้ แต่เลเยอร์การดำเนินการจะกลายเป็นคอขวดถัดไปที่ส่งผลต่อประสิทธิภาพการทำงานของ Rollup หากความเร็วในการดำเนินการของเลเยอร์การดำเนินการของ Layer2 ช้า ความต้องการในการทำธุรกรรมล้นจะแพร่กระจายไปยังเลเยอร์ 2 อื่น ๆ ซึ่งท้ายที่สุดจะทำให้เกิดการกระจายตัวของสภาพคล่อง ดังนั้นการปรับปรุงประสิทธิภาพของเลเยอร์การดำเนินการจึงมีความสำคัญเช่นกัน โดยทำหน้าที่เป็นเกณฑ์อื่นเหนือเลเยอร์ DA

การเพิ่มประสิทธิภาพของ opBNB ในเลเยอร์การดำเนินการ: การเพิ่มประสิทธิภาพแคช

เมื่อคนส่วนใหญ่พูดคุยเกี่ยวกับปัญหาคอขวดด้านประสิทธิภาพของเลเยอร์การดำเนินการบล็อกเชน พวกเขาจะกล่าวถึงปัญหาคอขวดที่สำคัญสองประการอย่างหลีกเลี่ยงไม่ได้ ได้แก่ การดำเนินการอนุกรมแบบเธรดเดี่ยวของ EVM ที่ล้มเหลวในการใช้ CPU อย่างเต็มที่ และการค้นหาข้อมูลที่ไม่มีประสิทธิภาพของ Merkle Patricia Trie ที่ Ethereum นำมาใช้ โดยพื้นฐานแล้ว กลยุทธ์การปรับขนาดสำหรับเลเยอร์การดำเนินการนั้นเกี่ยวข้องกับการใช้ทรัพยากร CPU อย่างมีประสิทธิภาพมากขึ้น และทำให้แน่ใจว่า CPU สามารถเข้าถึงข้อมูลได้โดยเร็วที่สุด

โซลูชันการปรับให้เหมาะสมสำหรับการดำเนินการ EVM แบบอนุกรมและ Merkle Patricia Trie มักจะซับซ้อนและท้าทายในการใช้งาน ในขณะที่ความพยายามที่คุ้มค่ากว่ามักจะมุ่งเน้นไปที่การปรับแคชให้เหมาะสม ในความเป็นจริง การเพิ่มประสิทธิภาพแคชนำเรากลับไปสู่ประเด็นที่มีการพูดคุยกันบ่อยครั้งในบริบท Web2 แบบดั้งเดิมและแม้แต่ในตำราเรียน

โดยทั่วไปแล้ว ความเร็วที่ CPU ดึงข้อมูลจากหน่วยความจำจะเร็วกว่าการดึงข้อมูลจากดิสก์หลายร้อยเท่า ตัวอย่างเช่น การดึงข้อมูลจากหน่วยความจำอาจใช้เวลาเพียง 0.1 วินาที ในขณะที่การดึงข้อมูลจากดิสก์อาจใช้เวลา 10 วินาที ดังนั้น การลดค่าใช้จ่ายที่เกิดจากการอ่านและเขียนดิสก์ เช่น การเพิ่มประสิทธิภาพแคช จึงกลายเป็นส่วนสำคัญในการเพิ่มประสิทธิภาพเลเยอร์การดำเนินการบล็อกเชน

ใน Ethereum และเครือข่ายสาธารณะอื่นๆ ส่วนใหญ่ ฐานข้อมูลที่บันทึกสถานะที่อยู่บนเครือข่ายจะถูกจัดเก็บไว้บนดิสก์ทั้งหมด ในขณะที่สิ่งที่เรียกว่า World State trie เป็นเพียงดัชนีของฐานข้อมูลนี้ หรือไดเร็กทอรีที่ใช้สำหรับการค้นหาข้อมูล ทุกครั้งที่ EVM ดำเนินการตามสัญญา จะต้องเข้าถึงสถานะที่อยู่ที่เกี่ยวข้อง การดึงข้อมูลจากฐานข้อมูลบนดิสก์ทีละรายการจะทำให้การดำเนินการธุรกรรมช้าลงอย่างมาก ดังนั้นการตั้งค่าแคชภายนอกฐานข้อมูล/ดิสก์จึงเป็นวิธีที่จำเป็นในการเร่งความเร็ว

opBNB ใช้โซลูชันเพิ่มประสิทธิภาพแคชที่ใช้โดย BNB Chain โดยตรง ตามข้อมูลที่เปิดเผยโดย NodeReal ซึ่งเป็นพันธมิตรของ opBNB ห่วงโซ่ BSC แรกสุดได้ตั้งค่าแคชสามชั้นระหว่าง EVM และฐานข้อมูล LevelDB ที่จัดเก็บสถานะ แนวคิดการออกแบบคล้ายกับแคชสามระดับแบบดั้งเดิม โดยที่ข้อมูลที่มีความถี่ในการเข้าถึงสูงกว่าจะถูกเก็บไว้ในแคช ซึ่งช่วยให้ CPU สามารถค้นหาข้อมูลที่ต้องการในแคชได้ก่อน หากอัตราการเข้าถึงแคชสูงเพียงพอ CPU ก็ไม่จำเป็นต้องพึ่งพาดิสก์มากเกินไปในการดึงข้อมูล ส่งผลให้ความเร็วในการดำเนินการโดยรวมดีขึ้นอย่างเห็นได้ชัด

ต่อมา NodeReal ได้เพิ่มฟีเจอร์นอกเหนือจากนี้ ซึ่งใช้ประโยชน์จากคอร์ CPU ที่ไม่ได้ใช้เพื่ออ่านข้อมูลที่ EVM จะต้องประมวลผลในอนาคตจากฐานข้อมูลล่วงหน้าและจัดเก็บไว้ในแคช คุณลักษณะนี้เรียกว่า "สถานะการโหลดล่วงหน้า"

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

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

กล่าวโดยสรุป opBNB สามารถประมวลผลการถ่ายโอนง่าย ๆ สูงสุด 4,761 รายการต่อวินาที การถ่ายโอนโทเค็น ERC20 15,003,000 รายการต่อวินาที และการดำเนินการ SWAP ประมาณ 5,001,000 รายการต่อวินาที โดยอิงจากข้อมูลธุรกรรมที่สังเกตได้จาก blockchain explorer เมื่อเปรียบเทียบพารามิเตอร์ปัจจุบัน ขีดจำกัด TPS ของ opBNB คือ 40 เท่าของ Ethereum มากกว่า 2 เท่าของ BNB Chain และมากกว่า 6 เท่าของการมองโลกในแง่ดี

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

สำหรับ BNB Chain ที่มีเลเยอร์ DA ที่มีทรูพุตสูง เช่น opBNB ผลกระทบที่เพิ่มขึ้นสองเท่าของการปรับขนาดนั้นมีค่า โดยเฉพาะอย่างยิ่งเมื่อพิจารณาว่า BNB Chain สามารถโฮสต์โปรเจ็กต์การปรับขนาดดังกล่าวได้หลายโครงการ สามารถคาดการณ์ได้ว่า BNB Chain ได้รวมโซลูชัน Layer2 ที่นำโดย opBNB ไว้ในแผนเชิงกลยุทธ์แล้ว และจะยังคงนำโครงการบล็อกเชนแบบโมดูลาร์เพิ่มเติมต่อไป รวมถึงการแนะนำการพิสูจน์ ZK ใน opBNB และการจัดหาเลเยอร์ DA ที่พร้อมใช้งานสูงพร้อมโครงสร้างพื้นฐานเสริม เช่น GreenField ใน ความพยายามที่จะแข่งขันหรือร่วมมือกับระบบนิเวศ Ethereum Layer2

ในยุคที่ Layered Scaling กลายเป็นกระแส เชนสาธารณะอื่นๆ จะรีบเร่งเพื่อสนับสนุนโปรเจ็กต์ Layer2 ของตัวเองหรือไม่นั้น ก็ต้องรอดูกันต่อไป แต่ไม่ต้องสงสัยเลยว่า การเปลี่ยนกระบวนทัศน์ไปสู่โครงสร้างพื้นฐานบล็อกเชนแบบโมดูลาร์กำลังเกิดขึ้นแล้ว

ข้อสงวนสิทธิ์：

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