坎昆升级将至，如何提前布局？
ผู้เขียนต้นฉบับ: ผู้สนับสนุนหลักของ Biteye Fishery Isla
บรรณาธิการต้นฉบับ: Crush ผู้สนับสนุนหลักของ Biteye
ที่มา: @BiteyeCN
การอัปเกรดเครือข่าย Ethereum เวอร์ชัน Dencun testnet เปิดตัวบน Goerli testnet เมื่อวันที่ 17 มกราคม 2024 และ Sepolia testnet เปิดตัวได้สำเร็จในวันที่ 30 มกราคม การอัปเกรด Dencun กำลังเข้าใกล้เรามากขึ้นเรื่อยๆ
หลังจากอัปเกรด Holesky testnet อีกครั้งในวันที่ 7 กุมภาพันธ์ จะเป็นการอัพเกรด mainnetในปัจจุบันการอัพเกรดแคนคูนการเปิดตัว mainnet ได้รับการยืนยันอย่างเป็นทางการเมื่อวันที่ 13 มีนาคม
เกือบทุกการอัพเกรด Ethereum จะมาพร้อมกับคลื่นของราคาธีม ย้อนกลับไปที่การอัพเกรด Ethereum ครั้งล่าสุดในเซี่ยงไฮ้เมื่อวันที่ 12 เมษายน 2023 โครงการที่เกี่ยวข้องกับ POS เป็นที่ต้องการของตลาด
หากปฏิบัติตามประสบการณ์ก่อนหน้านี้ การอัพเกรด Dencun นี้จะมีโอกาสที่จะปรับใช้ล่วงหน้าด้วย
เนื่องจากเนื้อหาทางเทคนิคที่อยู่เบื้องหลังการอัพเกรด Dencun นั้นค่อนข้างคลุมเครือ จึงไม่สามารถสรุปเป็นประโยคเดียวได้ เช่น Ethereum เปลี่ยนจาก PoW เป็น PoS เช่นเดียวกับการอัพเกรดที่ Shanghai ทำให้ยากต่อการเข้าใจประเด็นสำคัญของเค้าโครง
ดังนั้นบทความนี้จะใช้ภาษาที่เข้าใจง่ายเพื่ออธิบายรายละเอียดทางเทคนิคของการอัพเกรด Dencun และช่วยผู้อ่านแยกแยะบริบทระหว่างการอัพเกรดนี้และความพร้อมใช้งานของข้อมูล DA และเลเยอร์ 2
EIP 4484
EIP-4844 เป็นข้อเสนอที่สำคัญที่สุดในการอัปเกรด Dencun นี้ ซึ่งถือเป็นก้าวที่สำคัญและใช้งานได้จริงสำหรับ Ethereum ในการขยายในลักษณะกระจายอำนาจ
โดยทั่วไปแล้ว เลเยอร์ที่สองของ Ethereum ในปัจจุบันจำเป็นต้องส่งธุรกรรมที่เกิดขึ้นบนเลเยอร์ที่สองไปยังข้อมูลการโทรของเครือข่ายหลัก Ethereum สำหรับโหนดเพื่อตรวจสอบความถูกต้องของบล็อกที่สร้างโดยเครือข่ายเลเยอร์ที่สอง
ปัญหาที่เกิดจากสิ่งนี้คือแม้ว่าข้อมูลธุรกรรมจะถูกบีบอัดมากที่สุดเท่าที่จะเป็นไปได้ แต่ปริมาณธุรกรรมขนาดใหญ่ของชั้นที่สองคูณด้วยฐานต้นทุนการจัดเก็บข้อมูลที่สูงของเครือข่ายหลัก Ethereum ยังคงมีปริมาณมหาศาลสำหรับโหนดชั้นที่สองและ ผู้ใช้ชั้นที่ 2 ไม่ใช่ค่าใช้จ่ายเล็กน้อย ปัจจัยด้านราคาเพียงอย่างเดียวจะทำให้เลเยอร์ที่สองสูญเสียผู้ใช้จำนวนมากไปยังเครือข่ายด้านข้าง
EIP 4484 สร้างพื้นที่จัดเก็บข้อมูลใหม่ที่ถูกกว่าBLOB(Binary Large Object, binary large object) และใช้วิธีการที่เรียกว่า BLOB storage space ที่สามารถชี้ไปยัง"BLOB-Carrying Transaction"ประเภทธุรกรรมใหม่จะแทนที่ข้อมูลธุรกรรมที่ต้องจัดเก็บไว้ใน calldata ก่อนอัปเกรด ช่วยให้ชั้นที่สองของระบบนิเวศ Ethereum ประหยัดค่าน้ำมัน
เหตุใดที่เก็บข้อมูล BLOB จึงมีราคาถูก
ดังที่เราทุกคนทราบกันดีว่าราคาถูกมาพร้อมกับราคา และเหตุผลที่ข้อมูล BLOB มีราคาถูกกว่า Ethereum Calldata ธรรมดาที่มีขนาดใกล้เคียงกันก็คือ Ethereum Execution Layer (EL, EVM) ไม่สามารถเข้าถึงข้อมูล BLOB ได้จริงๆ
ในทางตรงกันข้าม EL สามารถเข้าถึงเฉพาะการอ้างอิงข้อมูล BLOB เท่านั้น และข้อมูลของ BLOB เองก็สามารถดาวน์โหลดและจัดเก็บโดยชั้นฉันทามติ (CL หรือที่เรียกว่าโหนดบีคอน) ของ Ethereum เท่านั้น จำนวนหน่วยความจำและการคำนวณที่ใช้สำหรับ พื้นที่เก็บข้อมูลน้อยกว่า Ethereum ทั่วไปมาก Calldata
นอกจากนี้ BLOB ยังมีคุณลักษณะที่สามารถจัดเก็บได้ในระยะเวลาที่จำกัดเท่านั้น (ปกติประมาณ 18 วัน) และจะไม่ขยายอย่างไม่สิ้นสุดเหมือนกับขนาดของบัญชีแยกประเภท Ethereum
ระยะเวลาความถูกต้องของพื้นที่เก็บข้อมูล BLOB
ตรงกันข้ามกับบัญชีแยกประเภทถาวรของบล็อกเชน BLOB เป็นที่เก็บข้อมูลชั่วคราวที่พร้อมใช้งานสำหรับยุค 4096 หรือประมาณ 18 วัน
หลังจากหมดอายุ ไคลเอนต์ที่เป็นเอกฉันท์ส่วนใหญ่จะไม่สามารถเรียกข้อมูลเฉพาะใน BLOB ได้ อย่างไรก็ตาม หลักฐานการมีอยู่ก่อนหน้านี้จะยังคงอยู่ใน mainnet ในรูปแบบของข้อผูกพัน KZG และจะถูกเก็บไว้อย่างถาวรบน Ethereum mainnet
ทำไมต้องเลือก 18 วัน? นี่เป็นการแลกเปลี่ยนระหว่างต้นทุนและประสิทธิภาพของพื้นที่จัดเก็บข้อมูล
ขั้นแรก ให้พิจารณาผู้รับประโยชน์ตามสัญชาตญาณที่สุดของการอัพเกรดนี้Optimistic Rollups(เช่น: Arbitrum และ Optimism) เนื่องจากตามการตั้งค่าของ Optimistic Rollups มีกรอบเวลาพิสูจน์ข้อผิดพลาด (Fruad Proof) ภายใน 7 วัน
ข้อมูลธุรกรรมที่จัดเก็บไว้ใน Blob เป็นสิ่งที่ Optimistic Rollups ต้องการเมื่อเริ่มการท้าทาย
ดังนั้น ระยะเวลาที่ถูกต้องของ Blob ต้องแน่ใจว่าสามารถเข้าถึงการพิสูจน์ความล้มเหลวของ Optimistic Rollups ได้ เพื่อความง่าย ชุมชน Ethereum เลือกยกกำลังที่ 12 ของ 2 (4096 epochs มาจาก 2^12 และหนึ่ง epoch อยู่ที่ประมาณ 6.4 นาที)
ธุรกรรมที่ดำเนินการ BLOB และ BLOB
การทำความเข้าใจความสัมพันธ์ระหว่างทั้งสองเป็นสิ่งสำคัญในการทำความเข้าใจบทบาทของ BLOB ในความพร้อมของข้อมูล (DA)
แบบแรกคือข้อเสนอ EIP-4484 ทั้งหมดและเป็นธุรกรรมประเภทใหม่ ในขณะที่แบบหลังสามารถเข้าใจได้ว่าเป็นสถานที่จัดเก็บชั่วคราวสำหรับธุรกรรมเลเยอร์ 2
ความสัมพันธ์ระหว่างทั้งสองสามารถเข้าใจได้เนื่องจากข้อมูลส่วนใหญ่ในอดีต (ข้อมูลธุรกรรมเลเยอร์ 2) ถูกเก็บไว้ในส่วนหลัง ข้อมูลที่เหลือซึ่งก็คือความมุ่งมั่นของข้อมูล BLOB จะถูกจัดเก็บไว้ในข้อมูลการโทรของเครือข่ายหลัก กล่าวอีกนัยหนึ่ง EVM สามารถอ่านคำสัญญาได้
Commitment สามารถจินตนาการได้ว่าเป็นการสร้างธุรกรรมทั้งหมดใน BLOB ลงในแผนผัง Merkle จากนั้นจึงมีเพียง Merkle root ซึ่งเป็น Commitment เท่านั้นที่สามารถเข้าถึงได้โดยสัญญา
สิ่งนี้สามารถทำได้อย่างชาญฉลาด: แม้ว่า EVM จะไม่สามารถทราบเนื้อหาเฉพาะของ BLOB ได้ แต่สัญญา EVM สามารถตรวจสอบความถูกต้องของข้อมูลธุรกรรมได้โดยทราบข้อผูกพัน
ความสัมพันธ์ระหว่าง BLOB และเลเยอร์ 2
เทคโนโลยี Rollup บรรลุความพร้อมใช้งานของข้อมูล (DA) โดยการอัปโหลดข้อมูลไปยังเครือข่ายหลักของ Ethereum แต่ไม่ได้มีวัตถุประสงค์เพื่อให้สัญญาอัจฉริยะของ L1 อ่านหรือตรวจสอบข้อมูลที่อัปโหลดเหล่านี้ได้โดยตรง
วัตถุประสงค์ของการอัปโหลดข้อมูลธุรกรรมไปยัง L1 คือเพื่อให้ผู้เข้าร่วมทุกคนสามารถดูข้อมูลได้
ก่อนการอัพเกรด Dencun ตามที่กล่าวไว้ข้างต้น Op-rollup จะเผยแพร่ข้อมูลธุรกรรมไปยัง Ethereum ในรูปแบบ Calldata ดังนั้นใครๆ ก็สามารถใช้ข้อมูลธุรกรรมเหล่านี้เพื่อสร้างสถานะและตรวจสอบความถูกต้องของเครือข่ายเลเยอร์ที่สองได้
ไม่ใช่เรื่องยากที่จะเห็นว่าข้อมูลธุรกรรม Rollup ต้องมีราคาถูก + เปิดกว้าง และโปร่งใส Calldata ไม่ใช่ที่ที่ดีในการจัดเก็บข้อมูลธุรกรรมสำหรับเลเยอร์ที่สองโดยเฉพาะ และ BLOB-Carrying Transaction ได้รับการออกแบบมาเพื่อ Rollup โดยเฉพาะ
อ่านแล้วอาจเกิดคำถามในใจว่าข้อมูลธุรกรรมประเภทนี้ดูไม่สำคัญ มีประโยชน์อย่างไร?
อันที่จริง ข้อมูลธุรกรรมจะถูกใช้ในบางกรณีเท่านั้น:
สำหรับ Optimistic Rollup ตามสมมติฐานของความไว้วางใจ มีโอกาสเกิดปัญหาความไม่ซื่อสัตย์ ในขณะนี้ บันทึกธุรกรรมที่อัปโหลดโดย Rollup มีประโยชน์ ผู้ใช้สามารถใช้ข้อมูลนี้เพื่อเริ่มต้นความท้าทายในการทำธุรกรรม (หลักฐานการฉ้อโกง)
สำหรับ ZK Rollup การพิสูจน์ความรู้แบบศูนย์ได้พิสูจน์แล้วว่าการอัปเดตสถานะนั้นถูกต้อง การอัปโหลดข้อมูลมีไว้เพื่อให้ผู้ใช้สามารถคำนวณสถานะทั้งหมดได้ด้วยตัวเองเท่านั้น เมื่อโหนดเลเยอร์ที่สองไม่สามารถทำงานได้อย่างถูกต้อง กลไก Escape Hatch (Escape Hatch, ซึ่งต้องใช้แผนผังสถานะ L2 ที่สมบูรณ์) จะกล่าวถึงในส่วนสุดท้าย)
ซึ่งหมายความว่าสถานการณ์ที่สัญญาใช้ข้อมูลธุรกรรมจริงนั้นมีจำกัดมาก แม้แต่ในความท้าทายในการทำธุรกรรม Optimistic Rollup ก็จำเป็นต้องส่งหลักฐาน (สถานะ) เท่านั้นเพื่อพิสูจน์ว่าข้อมูลธุรกรรม มีอยู่ ทันที และไม่จำเป็นต้องเก็บรายละเอียดธุรกรรมไว้ในเครือข่ายหลักล่วงหน้า
ดังนั้นหากเราใส่ข้อมูลธุรกรรมไว้ในองค์ประกอบ BLOB แม้ว่าสัญญาจะไม่สามารถเข้าถึงได้ แต่สัญญา mainnet ก็สามารถจัดเก็บ Commitment ของ BLOB นี้
ในอนาคต หากกลไกการท้าทายต้องการธุรกรรมบางอย่าง เราจำเป็นต้องให้ข้อมูลของธุรกรรมนั้นเท่านั้น ตราบใดที่สามารถจับคู่ได้ สิ่งนี้จะโน้มน้าวสัญญาและให้ข้อมูลธุรกรรมสำหรับกลไกความท้าทายที่จะใช้
สิ่งนี้ไม่เพียงใช้ประโยชน์จากความเปิดกว้างและความโปร่งใสของข้อมูลธุรกรรมเท่านั้น แต่ยังช่วยหลีกเลี่ยงค่าใช้จ่ายมหาศาลในการป้อนข้อมูลทั้งหมดลงในสัญญาล่วงหน้าอีกด้วย
ด้วยการบันทึกข้อผูกพันเท่านั้น ข้อมูลธุรกรรมสามารถตรวจสอบได้พร้อมทั้งปรับต้นทุนให้เหมาะสมอย่างมาก นี่เป็นโซลูชันที่ชาญฉลาดและมีประสิทธิภาพสำหรับการอัปโหลดข้อมูลธุรกรรมโดยใช้เทคโนโลยี Rollup
ควรสังเกตว่าในการทำงานจริงของ Dencun จะไม่ใช้วิธีการเดียวกันCelestiaCommitment ถูกสร้างขึ้นในลักษณะเดียวกันกับแผนผัง Merkle แต่ใช้อัลกอริธึม KZG (Kate-Zaverucha-Goldberg, Polynomial Commitment) อันชาญฉลาด
เมื่อเปรียบเทียบกับ Merkle tree proof กระบวนการสร้าง KZG Proof นั้นค่อนข้างซับซ้อน แต่ปริมาณการตรวจสอบน้อยกว่าและขั้นตอนการตรวจสอบง่ายกว่า อย่างไรก็ตาม ข้อเสียคือต้องใช้การตั้งค่าที่น่าเชื่อถือ (ceremony.ethereum.org ได้สิ้นสุดลงแล้ว) และ ไม่มีความสามารถในการโจมตีด้วยคอมพิวเตอร์ต่อต้านควอนตัม (Dencun ใช้วิธี Version Hash และวิธีการตรวจสอบอื่น ๆ สามารถแทนที่ได้หากจำเป็น)
สำหรับโปรเจ็กต์ DA Celestia ที่ได้รับความนิยมในขณะนี้นั้นใช้ตัวแปรของแผนผัง Merkle เมื่อเปรียบเทียบกับ KZG นั้นจะขึ้นอยู่กับความสมบูรณ์ของโหนดในระดับหนึ่ง แต่จะช่วยลดข้อกำหนดเกณฑ์ขั้นต่ำสำหรับทรัพยากรการประมวลผลระหว่างโหนดและรักษา ความเสถียรของเครือข่าย คุณสมบัติแบบกระจายอำนาจ
โอกาสเดนคุน
แม้ว่า Eip 4844 จะลดต้นทุนและเพิ่มประสิทธิภาพสำหรับเลเยอร์ที่สอง แต่ก็ยังมีความเสี่ยงด้านความปลอดภัย ซึ่งยังนำมาซึ่งโอกาสใหม่ๆ อีกด้วย
เพื่อทำความเข้าใจว่าทำไม เราต้องกลับไปที่กลไกการหลบหนีหรือกลไกการบังคับถอนตามที่กล่าวข้างต้น
เมื่อโหนดเลเยอร์ 2 ถูกปิดใช้งาน กลไกนี้สามารถรับประกันได้ว่าเงินทุนของผู้ใช้จะถูกส่งกลับไปยังเครือข่ายหลักอย่างปลอดภัย ข้อกำหนดเบื้องต้นสำหรับการเปิดใช้งานกลไกนี้คือผู้ใช้จำเป็นต้องได้รับแผนผังสถานะที่สมบูรณ์ของเลเยอร์ 2
ภายใต้สถานการณ์ปกติ ผู้ใช้เพียงแค่ค้นหาโหนดแบบเต็มของเลเยอร์ 2 เพื่อขอข้อมูล สร้าง Merkle Proof จากนั้นจึงส่งไปยังสัญญา Mainnet เพื่อพิสูจน์ความถูกต้องตามกฎหมายของการถอนเงิน
แต่อย่าลืมว่าผู้ใช้ต้องการเปิดใช้งานกลไก Escape Hatch เพื่อออกจาก L2 อย่างแม่นยำ เนื่องจากโหนด L2 ได้ทำชั่ว หากโหนดทำชั่ว มีความเป็นไปได้สูงที่จะไม่ได้รับข้อมูลที่ต้องการจาก โหนด
นี่คือสิ่งที่ Vitalik มักเรียกว่าเป็นการโจมตีเพื่อระงับข้อมูล
ก่อน EIP-4844 บันทึกเลเยอร์ 2 แบบถาวรจะถูกบันทึกไว้บน mainnet เมื่อไม่มีโหนด Layer 2 ที่สามารถแสดงสถานะออฟไลน์โดยสมบูรณ์ได้
โหนดแบบเต็มนี้สามารถรับข้อมูลประวัติทั้งหมดที่เผยแพร่โดยซีเควนเซอร์เลเยอร์ 2 บนเครือข่ายหลักผ่านเครือข่ายหลัก Ethereum ผู้ใช้สามารถสร้างหลักฐาน Merkle ที่จำเป็นและส่งหลักฐานไปยังสัญญาบนเครือข่ายหลักเพื่อทำให้สินทรัพย์ L2 สมบูรณ์อย่างปลอดภัย อพยพ
หลังจาก EIP-4844 ข้อมูลเลเยอร์ 2 จะมีอยู่ใน BLOB ของโหนดเต็มของ Ethereum เท่านั้น และข้อมูลประวัติเมื่อ 18 วันที่แล้วจะถูกลบโดยอัตโนมัติ
ดังนั้นวิธีการในย่อหน้าก่อนหน้าในการรับ state tree ทั้งหมดโดยการซิงโครไนซ์เครือข่ายหลักจึงไม่สามารถทำได้อีกต่อไป หากคุณต้องการรับ state tree ที่สมบูรณ์ของ Layer 2 คุณสามารถใช้บุคคลที่สามเพื่อจัดเก็บ Ethereum BLOB ทั้งหมดได้ ข้อมูลสำหรับ Love Power Generation (ซึ่งควรเป็นโหนด Mainnet (ถูกลบโดยอัตโนมัติหลังจาก 18 วัน) หรือโหนดดั้งเดิมของเลเยอร์ 2 (น้อยมาก)
หลังจากที่ 4844 เข้าสู่สถานะออนไลน์ จะเป็นเรื่องยากมากสำหรับผู้ใช้ที่จะได้รับแผนผังสถานะที่สมบูรณ์ของเลเยอร์ 2 ด้วยวิธีที่น่าเชื่อถืออย่างสมบูรณ์
หากผู้ใช้ไม่มีวิธีที่เสถียรในการรับแผนผังสถานะเลเยอร์ 2 พวกเขาจะไม่สามารถดำเนินการถอนออกแบบบังคับได้ภายใต้สภาวะที่รุนแรง ดังนั้น 4844 จึงทำให้เกิดข้อบกพร่อง/ข้อบกพร่องด้านความปลอดภัยของเลเยอร์ 2 ในระดับหนึ่ง
เพื่อชดเชยการขาดการรักษาความปลอดภัย เราจำเป็นต้องมีโซลูชันการจัดเก็บข้อมูลที่ไม่น่าเชื่อถือและมีวงจรเศรษฐกิจที่เป็นบวก พื้นที่เก็บข้อมูลในที่นี้หมายถึงการเก็บรักษาข้อมูลใน Ethereum ในลักษณะที่ไม่ไว้วางใจเป็นหลัก ซึ่งแตกต่างจากเส้นทางการจัดเก็บข้อมูลในอดีตเนื่องจากยังมีคำว่า ไม่เชื่อถือ
Ethstorageสามารถแก้ปัญหาการไม่ต้องการความไว้วางใจและได้รับเงินทุนสองรอบจาก Ethereum Foundation
อาจกล่าวได้ว่าแนวคิดนี้สามารถตอบสนอง/ชดเชยเส้นทางที่อัปเกรดของ Dencun ได้อย่างแท้จริง และคุ้มค่าแก่การเอาใจใส่เป็นอย่างยิ่ง
ประการแรก ความสำคัญตามสัญชาตญาณที่สุดของ Ethstorage คือสามารถขยายเวลาที่มีอยู่ของ DA BLOB ในลักษณะกระจายอำนาจโดยสมบูรณ์ ชดเชยข้อบกพร่องด้านความปลอดภัยที่สั้นที่สุดของเลเยอร์ 2 หลังจาก 4844
นอกจากนี้ โซลูชัน L2 ที่มีอยู่ส่วนใหญ่มุ่งเน้นไปที่การขยายพลังการประมวลผลของ Ethereum เป็นหลัก เช่น การเพิ่ม TPS อย่างไรก็ตาม ความจำเป็นในการจัดเก็บข้อมูลจำนวนมากอย่างปลอดภัยบน Ethereum mainnet ได้เพิ่มสูงขึ้น โดยเฉพาะอย่างยิ่งเนื่องจากความนิยมของ dApps เช่น NFT และ DeFi
ตัวอย่างเช่น ความต้องการพื้นที่เก็บข้อมูลของ on-chain NFT นั้นชัดเจนมาก เนื่องจากผู้ใช้ไม่เพียงแต่เป็นเจ้าของโทเค็นของสัญญา NFT เท่านั้น แต่ยังเป็นเจ้าของอิมเมจบนลูกโซ่ด้วย Ethstorage สามารถแก้ไขปัญหาความน่าเชื่อถือเพิ่มเติมที่มาพร้อมกับการจัดเก็บภาพเหล่านี้ในบุคคลที่สามได้
สุดท้ายนี้ Ethstorage ยังสามารถแก้ปัญหาความต้องการส่วนหน้าของ dApps แบบกระจายอำนาจได้อีกด้วย โซลูชันที่มีอยู่ในปัจจุบันโฮสต์โดยเซิร์ฟเวอร์ส่วนกลางเป็นหลัก (ด้วย DNS) การตั้งค่านี้ทำให้เว็บไซต์เสี่ยงต่อการถูกเซ็นเซอร์และปัญหาอื่นๆ เช่น การไฮแจ็ก DNS การแฮ็กเว็บไซต์ หรือเซิร์ฟเวอร์ล่ม ตามที่เห็นได้จากเหตุการณ์ต่างๆ เช่น Tornado Cash
Ethstorage ยังอยู่ในขั้นตอนการทดสอบเครือข่ายเบื้องต้น และผู้ใช้ที่มองโลกในแง่ดีเกี่ยวกับโอกาสของเส้นทางนี้สามารถทดลองใช้ได้
