บทนำ

สิ่งที่บล็อกเชนเก็บและอ้างอิงขณะประมวลผลธุรกรรมเรียกว่าสถานะ บน Ethereum สถานะเป็นคุณสมบัติที่สนับสนุนความเห็นของโหนด ทุกโหนดเต็มต้องเก็บและอัปเดตสถานะนี้ในระหว่างช่วงบล็อกที่ถูกต้อง สถานะอย่างสำคัญที่มีให้บล็อกเชน มาพร้อมกับข้อเสีย; พวกเขาขยายตัวตามเวลา พวกเขาเป็นปัญหาใหญ่ในบล็อกเชน เช่น Bitcoin และ Ethereum เพราะการเพิ่มขนาดไปพร้อมกับความต้องการฮาร์ดแวร์ที่เพิ่มขึ้นเท่าเทียม ช่วงที่เกณฑ์ขนาดทำให้บางโหนดหายไปตามเวลา นำไปสู่การลำเรียงEIP-2935เสนอให้สร้างสถานะไร้สถานะใน Ethereum เพื่อปลดปล่อยโหนดจากภาระขนาด EIP-2935 เป็นข้อเสนอการปรับปรุงที่พยายามทำให้มีสถานะไร้สถานะโดยการเก็บและให้บริการแฮชบล็อกล่าสุด 8192 บล็อกจากสถานะสำหรับการดำเนินการไร้สถานะใน Ethereum

ภาพรวมสั้น ๆ ของโครงสร้างปัจจุบันของ Ethereum

บล็อก

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

Alt: การเปลี่ยนสถานะใน Ethereum

เมื่อบล็อกใหม่ถูกจัดการและถูกส่งออกพร้อมกับผู้ตรวจสอบบนเครือข่าย เหลือที่เหลือจะเพิ่มลงในพื้นที่เก็บข้อมูลของพวกเขาและอัปเดตสถานะโลกของพวกเขา ผู้ตรวจสอบของแต่ละบล็อกถูกเลือกแบบสุ่มโดยRandomize Decentralized Autonomous Organization (RANDAO)พารามิเตอร์ โครงสร้างบล็อกเป็นการเรียงลำดับอย่างเคร่งครัด และกระบวนการสร้างบล็อกและการเรียกรับความเห็นได้รับการระบุภายใต้โปรโตคอล Proof-of-Stake ของ Ethereum

บล็อกประกอบด้วยฟิลด์หลายรายการในส่วนหัวและตัวอย่างเช่น หัวบล็อกรวมถึง ช่อง, ผู้เสนอ, รากหลัก, รากสถานะ, และฟิลด์ตัวอย่าง ส่วนตัวอย่างรวมถึง การเปิดเผย randao, ข้อมูล eth1, สีสร้างสรรค์, proposer_slashings, attester_slashings, attestations, การฝากเงิน, voluntary_exits, sync_aggregate, และ execution_payload แต่ละฟิลด์มีพารามิเตอร์ที่แตกต่างกันในและจัดการความต้องการที่แตกต่างกัน

Ethereum’s 12-วินาทีช่วงเวลาสร้างบล็อก หรือที่เรียกว่า “สล็อต” มาจากการเปิดให้เวลาเพียงพอให้ผู้เข้าร่วมเครือข่ายซิงโครไนซ์กับบล็อกใหม่และตกลงกันเกี่ยวกับคอนเซนซัส ในช่วงเวลานี้:

1. ผู้เสนอบล็อกเลือกผู้ตรวจสอบแบบสุ่ม,
2. Validator รวมการทำธุรกรรมพร้อมกันและดำเนินการให้พวกเขาเพื่อกำหนดสถานะโลกใหม่,
3. พวกเขารวมข้อมูลนี้ในบล็อกใหม่และกระจายไปยังเซ็ตของผู้ตรวจสอบที่เหลือผ่านโปรโตคอลการนินทา
4. Validators อื่น ๆ ทำการดำเนินการซ้ำอีกครั้งกับธุรกรรมเพื่อให้แน่ใจถึงความถูกต้องและเห็นด้วยกับการเปลี่ยนแปลงสถานะโลกเป็นข้อตกลง
5. หากผู้ตรวจสอบยืนยันว่าบล็อกใหม่ถูกต้อง พวกเขาจะเพิ่มไปยังพื้นที่จัดเก็บของพวกเขา

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

เมื่อประมวลผลบล็อก Ethereum ใช้ฟังก์ชันแฮชเพื่อเก็บข้อมูลของบล็อกและลดมันเหลือเพียงสตริงที่ไม่ซ้ำกัน ในฟังก์ชันแฮชทุกอินพุทจะสร้างเอาต์พุทที่ไม่ซ้ำกัน ค่าแฮชในบล็อกคือส่วนที่ไม่เปลี่ยนแปลงได้เท่านั้น มันเปลี่ยนแปลงได้ด้วยการเผาETHที่ถือรวมทั้งหมด 1/3 อย่างไรก็ตาม จำนวนนี้มาจากการคำนวณแฮช Merkle trie ใหม่จนถึงจุดสำคัญ ผลลัพธ์ของกระบวนการแฮชสำหรับแต่ละบล็อกถูกส่งกลับมาด้วยพารามิเตอร์ blockHash พารามิเตอร์ blockHash รวมถึงข้อมูลทั้งหมดในบล็อก

ค่าแฮชของบล็อกและพารามิเตอร์ที่จำเป็นอื่น ๆ จะถูกเก็บไว้ใน Merkle tries โครงสร้าง Merkle trie ของ Ethereum ใช้กับเวอร์ชันที่แตกต่างกัน เช่น Merkle Patricia Trie

Merkle และ Merkle Patricia Tries

โครงสร้างต้นไม้ (Trie structures) โดยเฉพาะอย่างยิ่ง Merkle Tries เป็นพื้นฐานของการจัดเก็บบล็อกเชน โดยไม่มี Merkle tries บล็อกเชนก็จะกลายเป็นบล็อกเดียวที่ยากต่อการประมวลผลทุกครั้ง ด้วย Merkle tries หรือโครงสร้างต้นไม้ที่ทั่วไป บล็อกเชนสามารถบรรลุความสมบูรณ์ด้วยชิ้นส่วนพื้นฐาน นี้ทำให้พวกเขากลายเป็นผู้ร่วมเครือข่ายที่มีความต้องการฮาร์ดแวร์ต่ำ

Merkle Tries เป็นวิธีโครงสร้างของการแฮชจำนวนมากของชิ้นงานและแบ่งแยกออกเป็นส่วน ด้วยการทำเครื่องหมาย Merkelization ข้อมูลจะถูกจัดระเบียบเป็นคู่ แต่ละคู่ถูกแฮชร่วมกัน กระบวนการ Merkelization จะทำซ้ำจนกว่าจะได้ราก Merkle เดียว

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

ในสถานการณ์การจัดเก็บข้อมูล state trie Ethereum ใช้แผนที่คีย์-ค่า คีย์แทนที่อยู่ และค่าแทนการประกาศบัญชี State trie มีความเคลื่อนไหวมากกว่า binary trie ดังนั้นบัญชีใหม่สามารถถูกแทรกใหม่บ่อย และคีย์สามารถถูกแทรกและลบบ่อย กระบวนการนี้ต้องใช้โครงสร้างข้อมูลที่สามารถอัพเดตอย่างรวดเร็วโดยไม่ต้องคำนวณชุดข้อมูลทั้งหมดใหม่

รากของต้นไม้ขึ้นอยู่กับข้อมูลเท่านั่น ไม่ใช่ลำดับ การทำการอัพเดตข้อมูลในลำดับที่แตกต่างกันจะไม่เปลี่ยนแปลงรากเอง

Alt: ต้นไม้ Merkle ทวิรู

Ethereum ใช้ Merkle Patricia Trie ที่ปรับเปลี่ยนแล้ว ซึ่งมีคุณสมบัติบางอย่างจาก PATRICIA (Practical Algorithm to Retrieve Information Coded in Alphanumeric)และ Merkle Trie พร้อมกับการปรับเปลี่ยนตามไปด้วย โครงสร้างนี้เป็นโครงสร้างที่กำหนดเองและสามารถตรวจสอบได้ทางด้านคริปโตได้อย่างชัดเจน เดียวสร้าง state root ในโครงสร้างนี้คือ ด้วยการคำนวณมันจากแต่ละชิ้นของ state สองสถานะที่เหมือนกันสามารถพิสูจน์ได้ง่ายๆ โดยการเปรียบเทียบ root hash และ hashes ที่นำมาสู่มัน

ในที่สุดการปรับเปลี่ยนสถานะด้วยค่าที่แตกต่างกันนั้นเป็นไปไม่ได้เพราะจะส่งผลให้เกิด state root hash ที่แตกต่างกัน โครงสร้าง trie ทั้งหมดใน Ethereum's execution layer ใช้ Merkle Patricia Trie เครือข่ายมี trie สามชนิด: State Trie, Storage Trie และ Transaction Trie นอกจากนี้ทุกบล็อกมี Receipts Trie เป็นของตนเอง ในขณะที่ Merkle Patricia Tries เป็นประสิทธิภาพในหลายด้าน Ethereum มีแรงบันดาลใจในการแทนที่ด้วย Verkle Tries เพื่อบรรลุการเป็น statelessness

Alt: Merkle Patricia Trie

Gas

Gas เป็นคุณสมบัติที่จำเป็นใน EVM สำหรับการดำเนินการ โดย EVM ใช้และต้องการทรัพยากรทางคำนวณในการดำเนินการ การคืนค่าของพยาบาลเหล่านี้จะถูกจ่ายด้วยแก๊สเพื่อให้มั่นใจว่าความปลอดภัยของ EVM Gas fee ถูกคำนวณโดยจำนวนแก๊สที่ต้องการคูณด้วยราคาต่อหน่วย มันเป็นค่าที่เปลี่ยนแปลงได้และขึ้นอยู่กับประเภทของการดำเนินการ

Alt: https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf

EIP-1559 แนะนําการเปลี่ยนแปลงที่สําคัญบางอย่างในกลไกค่าธรรมเนียมการทําธุรกรรม การจ่ายเงินสําหรับก๊าซเพื่อรวมธุรกรรมในบล็อกทํางานด้วยวิธีการประมูลในอดีต ด้วย EIP-1559 มีขีด จํากัด ขั้นต่ําที่เรียกว่าค่าธรรมเนียมพื้นฐานและเคล็ดลับที่เรียกว่าค่าธรรมเนียมลําดับความสําคัญที่แนะนํา บล็อกถูกเสนอให้เริ่มต้นจากการทําธุรกรรมด้วยค่าธรรมเนียมลําดับความสําคัญสูงสุด หลังจากกระบวนการบล็อกค่าธรรมเนียมพื้นฐานจะถูกเผาและค่าธรรมเนียมลําดับความสําคัญจะถูกใช้เพื่อจูงใจผู้ตรวจสอบความถูกต้อง

สถานะ

สถานะบล็อกเชนสามารถนิยามได้เป็นชุดข้อมูล (หรือตัวแปร) ซึ่งบรรยายระบบบางอย่างในช่วงเวลาที่เฉพาะเจาะจง อินเทอร์เน็ตมีสถานะในตัวตั้งแต่เริ่มต้น แต่ถูกเก็บไว้บนเซิร์ฟเวอร์เพียงเครื่องเดียว ด้วย Web3 สถานะโลกถูกบำรุงรักษาบนเครือข่ายที่เปิดเผยและแจกจ่ายที่ได้รับการรักษาผ่านวิธีการที่ไม่มีความจำเป็นให้มีการกำหนดจากศูนย์ ทุกคนสามารถดูและตรวจสอบสถานะของเครือข่ายที่แจกจ่ายได้ตลอดเวลาที่ต้องการ

Ethereum รวมถึงบัญชี ยอดคงเหลือ สัญญาอัจฉริยะที่ถูกสร้างขึ้นและการเก็บข้อมูลที่เกี่ยวข้องในสถานะโลก Ethereum สถานะของ Ethereum เติบโตด้วยการเพิ่มและเปลี่ยนแปลงพารามิเตอร์เหล่านี้ การเติบโตของสถานะกลายเป็นปัญหาเมื่อต้นทุนฮาร์ดแวร์สำหรับโฮสติ้งโหนดเต็มรูปแบบกลายเป็นเรื่องที่ห้ามหาก หลังจากเผชิญกับความท้าทายเหล่านี้ Vitalik Buterin แนะนำแนวคิดของ Ethereum แบบ Stateless ในปี 2017 วิธีที่เสนอเพื่อแก้ไขการเติบโตของสถานะใน Ethereum รวมถึงการหมดอายุของข้อมูลและสถานะ

ความแตกต่างระหว่างการหมดอายุข้อมูลและการหมดอายุสถานะ

วันหมดอายุของข้อมูล

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

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

EIP-4444提供了实用的途径到@hBXHLw_9Qq2va4pRtI4bIA/ryzBaf7fJx?ref=ghost-2077.arvensis.systems":เปิดเที่ปุ่มในโดยเบื้อกต้องหาและปมุ่มเส้นทุกสีชอนแรมในเที่ยวนี้สุข้านั้นที่โจรส่วนทุกที่ว่างเจ็ดและที่เมื่อในที่สุข้านอยู่โดยของ

การหมดอายุของรัฐ

State Expiry มีวัตถุประสงค์ที่จะกำจัดสถานะจากโหนดบุคคลหากไม่ได้เข้าถึงเมื่อเร็ว การหมดอายุอาจถูกนำมาใช้โดยการสิ้นสุดภายใต้การเสียค่าเช่าหรือเวลา การหมดอายุโดยการเสียค่าเช่าหมายถึงการอัดธรรมเนียมบัญชีสำหรับการเก็บสถานะ ในทางตรงกันข้าม การหมดอายุโดยเวลาหมายถึงการทำให้บัญชีไม่ใช้งานหากมีการไม่ใช้งานเป็นระยะเวลาบางครั้ง

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

Stateless Ethereum

การแนะนำถึงสถานะที่ไม่มีสถานะและอีเทอเรียมที่ไม่มีสถานะ

Stateless Ethereum แนะนําแนวคิดใหม่ให้กับโปรโตคอลหลัก ตามหลักการแล้วการไร้รัฐไม่ได้หมายความว่ารัฐไม่มีอยู่จริง แต่หมายความว่าลูกค้าสามารถเลือกสถานะที่ต้องการรักษาไว้ได้ เมื่อลูกค้าได้รับบล็อกที่ผ่านการตรวจสอบแล้วพวกเขายังได้รับพยานที่เกี่ยวข้องสําหรับบล็อกนั้น พยานสําหรับแต่ละบล็อกประกอบด้วยข้อมูลทั้งหมดที่จําเป็นในการดําเนินธุรกรรมที่มีอยู่ในบล็อกนั้น

EIP-161เสนอวิธีการลดสถานะครั้งแรก อีเธอเรียมถูกโจมตีด้วยการปฏิบัติการปิดกั้น (DoS) และช่องโหว่นี้ทำให้สามารถสร้างบัญชีว่างที่เพิ่มสถานะโลกของอีเธอเรียม EIP-161 เสนอให้ลบบัญชีว่างที่มีค่าศูนย์ (0) ที่มาจากการโจมตีนี้ โดยมีค่าใช้จ่ายต่ำ การเสนอนี้ถูกดำเนินการ ส่งผลให้สถานะกลับคืน

ความพยายามอีกอย่างสู่ความไร้สถานะถูกเสนอผ่านทาง EIP-4788. ข้อเสนอนี้มีจุดประสงค์เพื่อเปิดเผยรากฐานของบล็อกโบนช์ใน EVM คล้ายกับวิธีการของสะพาน Eth1-Eth2การเชื่อมต่อ Beacon chain (ระดับความเห็น) และ execution layer ในข้อเสนอนี้ช่วยให้มีการเข้าถึงโดยที่เชื่อมั่นระดับต่ำระหว่าง EVM และ ระดับความเห็น

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

สถานะไร้รัฐใน Ethereum เป็นไปได้ทั้งในรูปแบบของสถานะไร้รัฐที่อ่อนแอ หรือสถานะไร้รัฐที่แข็งแรง

ปัจจุบันขาดความเข้มแข็ง

การสถานะที่ไม่แข็งแกร่งเป็นสถานะที่ไม่ต้องการการเก็บรักษาสถานะในโหนดทั้งหมด แต่มันแตกต่างกันที่โหนดทำการตรวจสอบการเปลี่ยนแปลงของสถานะ Ethereum มันขัดใจทำให้ความรับผิดชอบในการเก็บรักษาสถานะอยู่กับผู้เสนอบล็อก และต้องการโหนดอื่น ๆ ให้ตรวจสอบบล็อกโดยไม่เก็บข้อมูลสถานะเต็มรูปแบบ

ผู้เสนอบล็อกต้องเก็บข้อมูลสถานะเต็ม อย่างไรก็ตาม ลูกค้าผู้ตรวจสอบไม่จำเป็นต้องเก็บข้อมูลสถานะบนเครือข่าย แทนที่นั้น พวกเขาสามารถเก็บรากสถานะ (แฮชของสถานะทั้งหมด) การสถานะที่อ่อนแอต้องการการแยกผู้เสนอและผู้ก่อสร้าง (PBS)และVerkle triesการปฏิบัติ

ผู้เสนอสร้างพยานโดยใช้ข้อมูลสถานะเพื่อพิสูจน์การเปลี่ยนแปลงของสถานะ และผู้ตรวจสอบยืนยันการพิสูจน์กับเส้นรากของสถานะ

สถานะที่ไม่มีประจำ

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

อย่างไรก็ตาม การเปลี่ยนแปลงบางอย่างและคุณสมบัติบางอย่างสามารถใช้ในการบรรลุสถานะที่ไม่มีสถานะได้ EIP-2935 มีข้อเสนอที่จะให้บริการค่าแฮชบล็อกประวัติจากสถานะเพื่ออนุญาตให้ดำเนินการโดยไม่มีสถานะ

บทนำสู่ EIP-2935

EIP-2935 มีเป้าหมายที่จะบันทึกค่า hash บล็อกประวัติในสถานะบล็อกเชนในช่องจัดเก็บพิเศษที่เรียกว่า HISTORY_STORAGE_ADDRESS กระบวนการนี้จะทำให้สามารถดำเนินการโดยไม่ระบุสถานะได้โดยการเข้าถึงข้อมูลประวัติที่จำเป็นอย่างง่ายในไคลเอ็นต์ที่ไม่ระบุสถานะ

EIP-2935 มีแผนให้เก็บค่าแฮชบล็อกย้อนหลัง 8192 ตัวในสัญญาระบบเพื่อใช้เป็นส่วนหนึ่งของตรรกะการประมวลผลบล็อก ปัญหาที่ข้อเสนอนี้พยายามแก้คือการสมมติของ EVM ว่าลูกค้ามีแฮชบล็อกล่าสุด การเข้าใช้งานที่พึงประสงค์นี้ไม่สามารถนำไปใช้กับ Ethereum ในอนาคตและลูกค้าที่ไม่เก็บสถานะเป็นพิเศษ

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

การขยายขอบเขตของบล็อกที่ blockHash บริการไปยัง 8192 blocks จะช่วยให้การเปลี่ยนแปลงอย่างอ่อนโยนสู่วิธีการดำเนินการ Rollups สามารถได้รับประโยชน์จากหน้าต่างประวัติที่ยาวนี้โดยการสอบถามตรงๆที่สัญญานี้เนื่องจากข้อมูล blockHash ถูกเก็บไว้ในสัญญานี้ นอกจากนี้ EIP นี้จะสะดวกในการตรวจสอบพิสูจน์ที่เกี่ยวข้องกับปริมาณบล็อก 8192 ของ HISTORY_SERVE_WINDOW กับสถานะปัจจุบัน

เข้าใจ EIP-2935

EIP-2935 ช่วยให้ลูกค้า Ethereum โดยเฉพาะลูกค้าแบบ stateless สามารถเข้าถึงค่า hash บล็อกล่าสุดได้อย่างง่ายดาย โดยทำให้มีการเพิ่มพารามิเตอร์ใหม่ 4 ตัว

• BLOCKHASH_SERVE_WINDOW: บอกลูกค้าว่าควรเก็บรอบบล็อกย้อนหลังกี่ไว้ ค่าเริ่มต้นคือ 256
• HISTORY_SERVE_WINDOW: พารามิเตอร์นี้กำหนดว่าจะเก็บค่าแฮชของบล็อกกี่บล็อก ค่าเริ่มต้นคือ 8191
• SYSTEM_ADDRESS: ที่อยู่พิเศษ (เริ่มต้นแนะนำใน EIP-4788) ที่ทำหน้าที่เป็น "ผู้เรียก" สำหรับเขียนโครงสร้างข้อมูลบล็อกเฮช
• HISTORY_STORAGE_ADDRESS: ที่อยู่สัญญาที่บล็อกแฮชเหล่านี้ถูกเก็บไว้

มีข้อเสนอที่กำหนดข้อกำหนดให้บล็อกแฮชล่าสุดของ HISTORY_SERVE_WINDOW ถูกเก็บไว้ในการเก็บข้อมูลแหวนลูกเรือที่มีความยาวเท่ากับ HISTORY_SERVE_WINDOW

Ring Buffer

EIP-2935 ใช้คุณสมบัติเพิ่มเติมที่เรียกว่า ring buffer สำหรับการจัดเก็บชั่วคราว Ring buffer เป็นคุณสมบัติที่อนุญาตให้เครือข่ายนำเอาพื้นที่เก็บเดียวกันมาใช้ในการเก็บข้อมูลที่แตกต่างกัน พื้นที่เก็บข้อมูลจะถูก จำกัดใน ring buffer ที่ตำแหน่งเดียวกันทุกครั้ง Ring buffer ใน EIP-2935 ถูกใช้เพียงเพื่อให้บริการ HISTORY_SERVE_WINDOW ที่จำเป็นเท่านั้น เนื่องจาก EIP-4788 และ beacon state accumulators อนุญาตให้พิสูจน์ต่อลูกพี่ใดก็ได้

กฎเลือก Fork และข้อมูลเฉพาะ

หลังจากการ fork เมื่อเครือข่ายเริ่มด้วยความคำนึงถึง EIP พิจารณาเหล่านี้ พารามิเตอร์ HISTORY_STORAGE_ADDRESS จะถูกอ้างอิงว่า SYSTEM_ADDRESS ด้วย input block.parent.hash (ค่าเริ่มต้น 32 ไบต์) จำกัด gas ที่ 30.000.000 และค่าเป็น 0 กระบวนการนี้จะเรียกใช้ฟังก์ชัน set() ของสัญญาประวัติ

กระบวนการฟอร์กหลังการ提案 แตกต่างจากระบวนการฟอร์กปกติ การดำเนินการเซ็ต() นี้เป็นการดำเนินการของระบบทั่วไป แต่การเรียกใช้ตามหลักการเหล่านี้:

• ต้องดำเนินการจนเสร็จสิ้น
• ไม่ถือว่าเป็นการเรียกใช้งานต่อจำกัดของบล็อก
• ไม่ทำตามกลไกการเผา EIP-1559
• ถ้าไม่มีโค้ดที่อยู่ที่ HISTORY_STORAGE_ADDRESS การเรียกควรล้มเหลวโดยไม่มีข้อผิดพลาดที่ถาวร

กระบวนการนี้ต้องเติมช่วงบล็อก HISTORY_SERVE_WINDOW เพื่อตรงกับช่วงเริ่มต้นของแหวนบัฟเฟอร์ สัญญาประวัติจะมีเพียงแค่แฮชของบล็อกที่แตกและทำหน้าที่เป็นแฮชอ้างอิงและจุดเริ่มต้นใหม่ของการแฮช

สัญญาประวัติเราะของบล็อกจะมีการดำเนินการสองประการ: get() และ set() การดำเนินการ set() จะถูกเรียกใช้เมื่อผู้เรียกใช้ของสัญญาในธุรกรรมเป็นเท่ากับ SYSTEM_ADDRESS ซึ่งถูกนำเสนอด้วย EIP-4788 หากผู้เรียกและ SYSTEM_ADDRESS ไม่เท่ากันหรือไม่สอดคล้องกับเงื่อนไข get() การดำเนินการจะถูกเรียกใช้

การดำเนินการ get() ใช้ใน EVM เพื่อค้นหา block hashes โดยลูกค้าสามารถให้หมายเลขบล็อกที่ต้องการสอบถาม หากข้อมูลเข้า calldata ไม่ใช่ 32 ไบต์ (ซึ่งหมายความว่าเป็น block.parent.hash ที่ถูกต้อง) และหากคำขออยู่นอกช่วง ([block.number-HISTORY_SERVE_WINDOW, block.number-1]) จะย้อนกลับการทำธุรกรรม

set() นำ input block.parent.hash เป็น calldata เมื่อ caller เรียก contract ด้วย ธุรกรรม และตั้งค่าค่าพื้นที่เก็บข้อมูลเป็น calldata[0:32] ที่ block.number-1 % HISTORY_SERVE_WINDOW

HISTORY_STORAGE_ADDRESS จะถูกนำไปใช้งานผ่าน EIP-4788 ซึ่งถูกอ้างอิงด้านบนว่าเป็นวิธีการเข้าถึง block hashes ที่ EVM โดยตรงผ่าน layer ของความเห็นร่วม HISTORY_STORAGE_ADDRESS จะมีค่า nonce เป็น 1 และได้รับการยกเว้นจากมาตรฐานการล้างค่า nonce ศูนย์ของ EIP-161

ตรรกะการเปลี่ยนแปลง BLOCKHASH

ความกังวลเกี่ยวกับ EIP นี้คือว่าจะทำอย่างไรให้ตรรกะการแก้ปัญหา BLOCKHASH หลังจากการ fork ทั้งสองวิธีหลักที่กำลังพิจารณาคือ

• รอให้บล็อก HISTORY_SERVE_WINDOW สำหรับประวัติที่เกี่ยวข้องทั้งหมดยังคงอยู่
• เก็บค่าแฮชบล็อกของบล็อกล่าสุดทั้งหมดใน HISTORY_SERVE_WINDOW บล็อกบนบล็อกแขนง

นักพัฒนาเลือกตัวเลือกแรก เนื่องจากมันมีความประโยชน์มากกว่าเนื่องจากมันไม่ต้องการการเปลี่ยนแปลงชั่วคราวใด ๆ

ความแตกต่างระหว่าง EIP-2935 กับ EIP ที่คล้ายกันคืออะไร

มี EIP ที่เสนอมาก่อนหน้าเพื่ออนุญาตและบรรลุการดำเนินการแบบ stateless EIP-2935 แตกต่างจากข้อเสนอก่อนหน้าเหล่านี้เนื่องจากเป้าหมายที่เน้นความซับซ้อนที่ได้ระบุด้านล่าง

• การทำโครงสร้าง Trie: EIP-2935 ไม่ใช้โครงสร้างที่เหมือน trie ที่มีหลายชั้นและเลือกที่จะใช้รายการเดียวกันแทน อย่างต่างหาก EIP-4444 ได้เสนอการตัดแต่งข้อมูลทางประวัติศาสตร์ในการดำเนินการของผู้ใช้ที่เก่ากว่าหนึ่งปี EIP อื่น ๆ ที่มีความทะเยอทะยานที่คล้ายกันมี Verkle tries เป็นข้อกำหนด
• การเขียน EIP ในรหัส EVM: EIP-2935 ไม่ต้องการการเปลี่ยนแปลงใน EVM
• การจัดเก็บแฮชแบบซีเรียลที่ไม่จำกัด: การเก็บแฮชแบบซีเรียลแบบไม่จำกัดไม่มีประสิทธิภาพ EIP นี้เลือกที่จะแก้ปัญหานี้โดยการรวมแฮช

ข้อควรระวังเกี่ยวกับความปลอดภัย

เนื่องจาก EIP-2935 ใช้สมาร์ทคอนแทรค มันเสี่ยงต่อการโจมตีการย่อยของสาขา อย่างไรก็ตาม ขนาดของรากสถานะทำให้การพยานการอัปเดตใด ๆ ช้าลงและการโจมตีการย่อยมีค่าใช้จ่ายมากขึ้นอย่างมีนัย

มันสามารถนำอะไรมา

• ทำให้ระบบ Oracle ที่เชื่อถือได้เร็วขึ้น: ในระบบ Oracle ที่ใช้ Uniswap v2 เป็นพื้นฐาน ผู้ใดมีการเข้าถึง Ethereum node สามารถสร้างพิสูจน์ของการเก็บข้อมูลของ Uniswap และส่งมันเพื่อการตรวจสอบบนเชื่อมโยง ราคาเฉลี่ยถูกกำหนดระหว่างบล็อกปัจจุบันและบล็อกของพิสูจน์ที่มี, พร้อมกับพิสูจน์ที่ถูกตรวจสอบได้ถึง 256 บล็อก, เนื่องจาก blockHash รองรับได้ถึง 256 บล็อก โดยได้ประโยชน์จาก EIP-2935, กระบวนการนี้สามารถปรับปรุงได้โดยการอนุญาตให้เข้าถึง block hashes ที่เก่ากว่า ซึ่งหมายความว่าพิสูจน์สามารถถูกตรวจสอบในระยะเวลาที่ยาวกว่า
• การอนุญาตให้สัญญาพิจารณาการยืนยันสถานะในอดีตได้โดยไม่ต้องเชื่อ: การปรับปรุง EIP-2935 สร้างโอกาสให้สามารถดูข้อมูลบล็อกเชนจากภายใน EVM ได้โดยไม่ต้องเชื่อ ผู้ใช้บริการสามารถสอบถามประวัติ รับการแฮช และตรวจสอบกับโหนดอื่น ๆ แนวทางนี้สามารถทำให้ไคลเอ็นต์เบามั่นคงและง่ายต่อการใช้งาน
• การเชื่อมโยงระหว่าง L1 <> L2: ในการตรวจสอบข้อความจาก L2 L1 จําเป็นต้องรู้เกี่ยวกับรากสถานะ L2 และบล็อกแฮช อย่างไรก็ตาม L1 ในสถานะปัจจุบันไม่สามารถเข้าถึงแฮชบล็อกโดยพลการได้เนื่องจากขีด จํากัด ของก๊าซและข้อ จํากัด ทางสถาปัตยกรรม EIP-2935 ช่วยให้ L1 สามารถตรวจสอบข้อมูลประวัติโดยพลการด้วยความสามารถในการตรวจสอบหลักฐานการรวมสําหรับเหตุการณ์เก่า อํานาจการเข้าถึงและการตรวจสอบจะดีขึ้นและประสิทธิภาพการเชื่อมโยง

สรุป

EIP-2935 แทนที่จะเป็นขั้นตอนสำคัญสู่การบรรลุเป้าหมายระยะยาวของ Ethereum แบบ Stateless การเก็บข้อมูล hash block ล่าสุด 8192 บล็อกในสัญญาที่โครงสร้างที่เฉพาะเจาะจงภายในที่อยู่สถานะ แสดงถึงข้อ จำกัดพื้นฐานในการออกแบบปัจจุบัน การสมมติของ Ethereum ว่าลูกค้ามีการเข้าถึงข้อมูล hash block ล่าสุดอย่างมีเงื่อนไขอยู่แล้ว ในบริบทของการดำเนินการ Stateless ที่ลูกค้าไม่ได้รักษาสถานะเต็มรูปแบบอีกต่อไป การสมมตินี้ก็กลายเป็นเที่ยงอกเท่านั้น EIP-2935 แก้ไขปัญหานี้โดยการนำเสนอกลไลท์เวทีที่มีประสิทธิภาพและไม่เข้าขัดซึ่งช่วยให้ลูกค้า Stateless สามารถเข้าถึงข้อมูลประวัติที่จำเป็นโดยไม่ต้องแก้ไข EVM หรือพฤติกรรมบนโครงสร้างข้อมูลที่ซับซ้อนเช่น Verkle tries

นอกเหนือจากการดำเนินการโดยไม่มีสถานะ ข้อเสนอนี้ปลดล็อคประโยชน์ที่กว้างขวางมากขึ้นในระบบนิวเคลียร์เอเธอเรียม มันเสนอศักยภาพของออราเคิลที่ไม่มีความไว้วางใจ ขยายความสามารถของไคลเอ็นต์ที่เบา และเสริมสร้างความสามารถในการทำงานร่วมกันระหว่าง Layer 1 และ Layer 2 โดยการเปิดใช้การยืนยันข้อมูลสถานะเก่าอย่างเชื่อถือได้ การดำเนินการของมันขึ้นอยู่กับการออกแบบที่สะอาดและประหยัดแก๊ส โดยใช้การเก็บข้อมูลแบบ ring buffer และสัญญาระดับระบบที่หลีกเลี่ยงความจำเป็นต้องเขียนโค้ดลงใน EVM นำเสนอทั้งความง่ายและการขยายอย่างเท่าเทียม

เมื่อ Ethereum ยังคงพัฒนาไปสู่การกระจายอำนวยความสะดวกในการเข้าถึงข้อมูลมากขึ้น EIP-2935 ทำหน้าที่เป็นการปรับปรุงรากฐาน สร้างสะพัดระหว่างสถาปัตยกรรมแบบ stateful ปัจจุบันและอนาคตที่ไม่มีสถานะและซึ่งเป็นพื้นฐานสำหรับโครงสร้างพื้นฐานที่มีความแข็งแกร่ง มีประสิทธิภาพมากขึ้น และเป็นโครงสร้างที่ไม่มีการอนุญาตที่แขวนลอยข้ามระบบ blockchain

ข้อความปฏิเสธความรับผิดชอบ:

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