Solana Virtual Machine (SVM) กําลังถูกนํามาใช้อย่างกว้างขวางในฐานะเลเยอร์การดําเนินการสําหรับโซลูชัน Layer-2 (L2) ต่างๆ อย่างไรก็ตามข้อ จํากัด ที่สําคัญในการออกแบบดั้งเดิมของ SVM คือความคลุมเครือของรากเหง้าของรัฐทั่วโลก สิ่งนี้ก่อให้เกิดความท้าทายที่สําคัญสําหรับระบบสะสมซึ่งรากเหง้าของรัฐทั่วโลกมีความสําคัญต่อการรับรองความสมบูรณ์เปิดใช้งานการพิสูจน์การทุจริตและการสนับสนุนการดําเนินงานข้ามชั้น

ในการยกเลิกผู้เสนอจะส่งรากสถานะ L2 (ราก Merkle) ไปยัง Layer-1 (L1) เป็นระยะโดยกําหนดจุดตรวจสอบสําหรับห่วงโซ่ L2 จุดตรวจสอบเหล่านี้อนุญาตให้มีการพิสูจน์การรวมสําหรับสถานะบัญชีใด ๆ ทําให้สามารถดําเนินการแบบไร้สถานะจากจุดตรวจหนึ่งไปยังอีกจุดหนึ่งได้ หลักฐานการทุจริตอาศัยกลไกนี้ เนื่องจากผู้เข้าร่วมสามารถให้หลักฐานการรวมเพื่อตรวจสอบข้อมูลที่ถูกต้องในระหว่างข้อพิพาท นอกจากนี้ Merkle trees ยังช่วยเพิ่มความปลอดภัยของสะพาน Canonical โดยอนุญาตให้ผู้ใช้สร้างหลักฐานการรวมสําหรับธุรกรรมการถอนเงิน เพื่อให้มั่นใจถึงการโต้ตอบที่ไม่น่าเชื่อถือระหว่าง L2 และ L1

เพื่อที่จะแก้ไขปัญหาเหล่านี้เครือข่าย SOONเปิดเผยต้นไม้เมอร์เคิลเข้าสู่ชั้นการปฏิบัติ SVM ซึ่งทำให้ลูกค้าสามารถให้พิสูจน์การรวมอยู่ได้ SOON รวมกับ Proof-of-History โดยใช้รายการที่ไม่ซ้ำกันเพื่อฝังรากสถานะโดยตรงลงในบล็อกเชนที่ใช้ SVM ด้วยนวัตกรรมนี้ SOON stack สามารถรองรับรอลอัพที่ใช้ SVM ใหม่ที่มีความปลอดภัย เลื่อนขนาด และประโยชน์ที่เพิ่มขึ้น

ปัญหา Merklization ของ Solana

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

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

มาดูวิธีการทำ merklization บนเครือข่ายอื่น ๆ กันก่อน แล้วจึงระบุความท้าทายที่เกิดขึ้นจากโครงสร้างโปรโตคอลของ Solana

ต้นไม้เมอร์เคิลบนบิตคอยน์

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

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

Merkle Trees บน Ethereum

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

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

โชคดีที่ EVM ใช้โครงสร้าง trie สำคัญ 3 อย่างอย่างฉลาด ซึ่งเก็บรากของตนในส่วนหัวของบล็อกแต่ละบล็อก

• ต้นไม้สถานะ: ฐานข้อมูลขนาดใหญ่ของสถานะทั้งหมดบน Ethereum ซึ่งรวมถึงทุกที่อยู่ Ethereum และข้อมูลที่เก็บไว้ในแต่ละบัญชี สำหรับสมาร์ทคอนแทรค บัญชีเหล่านี้เก็บตีรที่อื่นที่เรียกว่า ต้นไม้จัดเก็บ, ซึ่งเป็นแผนที่ค่า-คีย์อีกอันของข้อมูลสมาร์ทคอนแทรคทั้งหมดสำหรับพื้นที่ที่อยู่ของมัน
• Transactions trie: ระบบจัดเก็บค่าของธุรกรรมทั้งหมดในบล็อก โดยที่คีย์คือ ID ของธุรกรรม และค่าคือข้อมูลของธุรกรรม
• Receipts trie: ต้นไม้ที่มีใบรับ (สถานะ, เหตุการณ์) จากทุกธุรกรรมในบล็อก ถูกทำให้เป็นรหัสโดยดัชนีของแต่ละธุรกรรมในบล็อก แต่ละใบรับมีข้อมูลเกี่ยวกับการดำเนินการของธุรกรรม รวมถึงรหัสสถานะหลังจากดำเนินการของธุรกรรมในต้นไม้สถานะ

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

Merkle Trees on Solana

หนึ่งในเหตุผลที่ทําให้ปริมาณงานสูงของ Solana คือความจริงที่ว่ามันไม่มีโครงสร้างหลายต้นที่ Ethereum มี ผู้นํา Solana คํานวณต้นไม้ Merkle เมื่อสร้างบล็อก แต่มีโครงสร้างแตกต่างจากภายใน EVM น่าเสียดายที่มีปัญหาสําหรับการยกเลิกที่ใช้ SVM

Solana ทำการ merklizes ธุรกรรมเป็นสิ่งที่เรียกว่า entries และสามารถมี entries หลายรายการต่อ slot ดังนั้น สามารถมีรากธุรกรรมหลายรายการต่อบล็อกได้ อีกทั้ง Solana คำนวณ Merkle root ของสถานะบัญชีเพียงครั้งเดียวต่อ epoch (ประมาณ 2.5 วัน) และรากนี้ไม่มีให้บน ledger

ในความเป็นจริง หัวบล็อก Solana ไม่มี Merkle roots เลย แต่มีข้อมูลเกี่ยวกับบล็อกก่อนหน้าและบล็อกปัจจุบันบล็อคแฮช, ซึ่งคำนวณผ่าน Solana’s พิสูจน์ของประวัติ อัลกอริทึม (PoH) PoH กําหนดให้ผู้ตรวจสอบต้องลงทะเบียน "เห็บ" อย่างต่อเนื่องโดยการแฮชรายการบล็อกซ้ํา ๆ ซึ่งอาจว่างเปล่าหรือมีชุดของธุรกรรม เห็บสุดท้าย (แฮช) ของอัลกอริทึม PoH คือ blockhash ของบล็อกนั้น

ปัญหาของ Proof of History คือมันทำให้การพิสูจน์สถานะยากมากที่จะทำจาก blockhash โซลานาถูกออกแบบมาในรูปแบบของการสตรีม PoH hashes เพื่อรักษาแนวคิดของเวลาที่ผ่านไป รากของธุรกรรมมีอยู่เฉพาะสำหรับ tick ของ PoH ที่มีการเข้ารหัสด้วยธุรกรรม ไม่ใช่บล็อคโดยรวม และไม่มีรากสถานะที่จัดเก็บอยู่ในอินทรี

อย่างไรก็ตาม ยังมีแฮชอีกตัวที่ลูกค้าสามารถใช้ได้: แฮชธนาคาร บางครั้งถูกเรียกว่า สล็อตแฮช แฮชธนาคารพร้อมให้บริการใน SlotHashes sysvarบัญชีซึ่งสามารถถามได้โดยลูกค้า ฮาชของธนาคารถูกสร้างขึ้นสำหรับแต่ละบล็อก (สล็อต) จากข้อมูลจำนวนเล็กน้อย

• แฮชธนาคารก่อนหน้า
• สถานะสต็อร์คแภม.
• จำนวนลายเซ็นการทำธุรกรรมในธนาคารเป็นไบต์
• บล็อกแฮชของธนาคารนี้
• เพียงครั้งเดียวต่อ epoch คือการแฮชของบัญชีทั้งหมดในฐานข้อมูลบัญชี
• เท่านั้นเมื่อคลัสเตอร์ได้ทำการรีสตาร์ท และแฮชของการ hard forks ใด ๆ ที่เกิดขึ้นจากการรีสตาร์ทของคลัสเตอร์

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

โซน โซลูชั่นเมอร์กไลเซชัน

เครือข่าย SOONเป็น SVM L2 บน Ethereum ในขณะที่การรวม merklization เข้ากับ SOON เราให้ความสำคัญกับการใช้โซลูชันที่ได้รับการยืนยันและเป็นที่ยอมรับเพื่อความมั่นคง โดยไม่ต้องประดิษฐ์วงจรใหม่ ในการตัดสินใจว่าจะใช้โครงสร้างข้อมูลหรืออัลกอริทึมการแฮช เราพิจารณาความสอดคล้องกับสัญญา L1 ของ Optimism Stack, ความสามารถในการผสานเข้ากับโครงสร้างของ Solana อย่างไร และว่าพวกเขาสามารถบรรลุประสิทธิภาพสูงในโมเดลบัญชีของ Solana หรือไม่

เราพบว่าเมื่อจำนวนบัญชีเพิ่มขึ้น รูปแบบการจัดเก็บ Merkle Patricia Trie (MPT) จะพึงพอใจ LSM-Tree ในที่สุดเราตัดสินใจที่จะรวม Erigon MPTโดยการพัฒนาจากงาน Rust ที่ยอดเยี่ยมที่ทำโดยrETHทีมและการเพิ่มการสนับสนุนสำหรับโมเดลบัญชี Solana

สถาปัตยกรรม

เหมือนกับที่กล่าวมาก่อนหน้านี้ ต้นไม้สถานะของ SOON เป็น MPT ที่สร้างขึ้นเพื่อสนับสนุนบัญชี Solana ดังนั้นเราได้กำหนดประเภทบัญชีที่เข้ากันได้กับ SVM เพื่อทำหน้าที่เป็นข้อมูลของทุกๆ โหนดใบไม้

struct TrieSolanaAccount {

lamports: u64,

data: Vec,

executable: bool,

rent_epoch: u64,

เจ้าของ: Pubkey,

}

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

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

outputRoot = keccak256(version, state_root, withdraw_root, l2_block_hash)

SOON MPT module รักษาโครงสร้างต้นไม้สองประเภทพร้อมกัน: State Trie สำหรับสถานะทั่วไป และ Withdraw Trie สำหรับธุรกรรมการถอนเงิน ผู้เสนอเสนอเป็นครั้งคราวสร้าง outputRoot โดยรากของสถานะและรากการถอนเงิน และยื่นให้ L1

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

บล็อกเชน Solana ประกอบด้วยสล็อตที่สร้างขึ้นโดยโมดูล PoH สล็อตประกอบด้วยรายการหลายรายการ โดยทุกรายการรวมถึง ticks และ ธุรกรรม ที่เน็ตเวิร์กและชั้นเก็บข้อมูลสล็อตถูกเก็บไว้และถูกส่งผ่านโดยใช้shredsเป็นหน่วยที่เล็กที่สุด ชิ้นส่วนสามารถแปลงเป็นและจากรายการได้

[derive(Serialize, Deserialize, Debug, Default, PartialEq, Eq, Clone)]

pub struct Entry {

จำนวนของ hashes ตั้งแต่ Entry ID ก่อนหน้า

จำนวน num_hashes: u64,

/// แฮช SHA-256 num_hashesหลังจากรหัสการเข้าสู่ระบบก่อนหน้า

แพ็กเกจแฮช: แฮช,

/// รายการซึ่งไม่เรียงลำดับของธุรกรรมที่สังเกตเห็นก่อนที่ ID รายการเข้า

/// สร้าง อาจมีการสังเกตเห็นก่อน ID รายการก่อนหน้าแต่อาจ

/// ย้อนกลับเข้าไปในรายการนี้เพื่อให้แนวทางในการตีความ ledger มีความแน่นอน

ธุรกรรม pub: Vec,

}

เราได้ติดตามโครงสร้างบล็อกเชนที่สร้างโดย PoH และเก็บโครงสร้างชิร์ดไว้ เพื่อให้เราสามารถ reuse ชั้นเก็บข้อมูลที่มีอยู่ของ Solana, ชั้นเครือข่าย, และกรอบงาน RPC โดยเพื่อเก็บข้อมูลเพิ่มเติมบนบล็อกเชน L2 เราได้นำเข้า UniqueEntry คุณลักษณะนี้ช่วยให้เราสามารถปรับแต่ง payload ของ entry และกำหนดกฎการตรวจสอบอิสระสำหรับข้อมูล

pub const UNIQUE_ENTRY_NUM_HASHES_FLAG: u64 = 0x8000_0000_0000_0000;

/// รายการที่เป็นเอกลักษณ์เป็นประเภทของรายการพิเศษ ซึ่งมีประโยชน์เมื่อเราต้องการเก็บข้อมูลบางอย่างใน

/// blockstore แต่ไม่ต้องการที่จะตรวจสอบ

///

/// การจัดหน้าnum_hashesคือ:

/// |…1 บิต…|…63 บิต…|

/// \ _ _/

/// \ \

ธง Custom Field

ลักษณะผับ UniqueEntry: ขนาด {

fn encode_to_entries(&self) -> Vec;

fn decode_from_entries(

   รายการ: impl IntoIterator<Item = Entry>,

) -> ผล<ตัวเอง, ข้อผิดพลาดที่เป็นเอกลักษณ์>;

}

pub fn unique_entry(custom_field: u64, hash: Hash) -> Entry {

รายการ {

   num_hashes: num_hashes(custom_field),   hash,   transactions: vec![],

}

}

pub fn num_hashes(custom_field: u64) -> u64 {

อ้าง! (custom_field < (1 << 63));

UNIQUE_ENTRY_NUM_HASHES_FLAG | custom_field

}

pub fn is_unique(entry: &Entry) -> bool {

entry.num_hashes & UNIQUE_ENTRY_NUM_HASHES_FLAG != 0

}

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

มาดูตัวอย่างการใช้สามรายการที่ไม่ซ้ำกันเพื่อเก็บข้อมูล slot hash, state root, และ withdraw root กัน

/// MPT root รายการเข้าสู่ระบบที่ไม่ซ้ำกัน

[derive(Default, Debug, Clone, PartialEq, Eq)]

pub struct MptRoot {

ช่องผับ: สล็อต,

pub state_root: B256,

pub withdrawal_root: B256,

}

impl UniqueEntry สําหรับ MptRoot {

fn encode_to_entries(&self) -> Vec {

   ให้สล็อตเข้าสู่ unique_entry(0, slot_to_hash(self.slot));   ให้สถานะรูทเข้าสู่ unique_entry(1, self.state_root.0.into());   ให้รากการถอนเข้าสู่ unique_entry(2, self.withdrawal_root.0.into());   vec![slot_entry, state_root_entry, withdrawal_root_entry]

}

fn decode_from_entries(
entries: impl IntoIterator,
) -> Result {

   ให้ entries เป็น entries.into_iter ();   ให้ entry = entries.next (). ok_or (UniqueEntryError :: NoMoreEntries)?;   ให้ slot = hash_to_slot (entry.hash);   ให้ entry = entries.next (). ok_or (UniqueEntryError :: NoMoreEntries)?;   ให้ state_root = B256 :: from (entry.hash.to_bytes ());   ให้ entry = entries.next (). ok_or (UniqueEntryError :: NoMoreEntries)?;   ให้ withdrawal_root = B256 :: from (entry.hash.to_bytes ());   Ok (MptRoot {       slot,       state_root,       withdrawal_root,   })

}
}

เนื่องจาก UniqueEntry กำหนดความหมายของ num_hashes ใหม่ จึงไม่สามารถประมวลผลได้ในช่วงการตรวจสอบ PoH ดังนั้น เริ่มต้นของกระบวนการตรวจสอบ เราจึงกรองรายการเข้าที่ไม่ซ้ำกันและส่งไปยังกระบวนการตรวจสอบที่กำหนดเองตามลำดับประเภทของข้อมูลของพวกเขา รายการที่เหลือที่เป็นปกติจะดำเนินการต่อในกระบวนการตรวจสอบ PoH ต้นฉบับ

การถอนและการสะพานเชื่อเชื่อ

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

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

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

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

ในสแต็ก OP แฮชของธุรกรรมการถอนของผู้ใช้ถูกเก็บไว้ในตัวแปรสถานะที่สอดคล้องกับOptimismPortal contract. อินเทอร์เฟซ RPC ที่ eth_getProof จึงถูกใช้เพื่อให้ผู้ใช้ได้รับพิสูจน์การรวมกันสำหรับธุรกรรมการถอนเฉพาะ

ไม่เหมือนกับ EVM ข้อมูลสัญญา SVM ถูกเก็บไว้ในฟิลด์ของบัญชี และมีประเภทของบัญชีทุกประเภทอยู่ในระดับชั้นเดียวกัน

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

[derive(Clone, Copy, Debug, PartialEq)]

ผับคําสั่งถอนธุรกรรม {

/// ตัวนับการถอน

ค่า nonce สาธารณะ: U256,

ผู้ใช้ที่ต้องการถอน

ผู้ส่งทั่วไป: Pubkey,

/// ที่อยู่ผู้ใช้ใน L1

pub target: Address,

/// จำนวนการถอนในลามพอร์ต

ค่า pub: U256,

/// ขีดจำกัดก๊าซใน L1

pub gas_limit: U256,

/// ข้อมูลการถอนใน L1

ข้อมูล pub: L1WithdrawalCalldata,

}

เรากำหนดโครงสร้างของธุรกรรมการถอนเงินเพื่อเก็บธุรกรรมการถอนเงินในฟิลด์ข้อมูลของ PDA

การออกแบบนี้ทำงานอย่างเดียวกับ OP Stack โดยเมื่อ outputRoot ที่มีการยกเลิกธุรกรรมถอนถูกส่งไปยัง L1 ผู้ใช้สามารถส่งพิสูจน์การรวมเพื่อธุรกรรมถอนไปที่ L1 เพื่อเริ่มระยะเวลาท้าทาย

ข้อพิสูจน์ข้อผิดพลาด

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

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

อย่างไรก็ตาม ณ จุดเริ่มต้นของกระบวนการนี้ ผู้ท้าทายต้องพิสูจน์ว่าข้อมูลเข้าเริ่มต้นทั้งหมดในสถานะ S1 เป็นข้อมูลที่ถูกต้อง ข้อมูลเริ่มต้นเหล่านี้รวมถึงสถานะของบัญชีที่มีส่วนร่วม (เช่น lamports, ข้อมูล, เจ้าของ, เป็นต้น) ใน SVM ทั้งนี้ แยกสถานะบัญชีจากการคำนวณโดยธรรมชาติ อย่างไรก็ตาม API SVM ของ Anza ช่วยให้บัญชีสามารถถ่ายทอดเข้าไปใน SVM ผ่าน TransactionProcessingCallback trait ดังที่แสดงด้านล่าง

pub trait TransactionProcessingCallback {

fn account_matches_owners(&self, บัญชี: &Pubkey, เจ้าของ: &[Pubkey]) -> ตัวเลือก;

fn get_account_shared_data(&self, pubkey: &Pubkey) -> Option;

fn add_builtin_account(&self, _name: &str, _program_id: &Pubkey) {}

}

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

สรุป

SOON กำลังเป็นจุดสำคัญสำหรับการพัฒนานิเวศ SVM โดยการรวม merklization ทำให้ SOON ทำการแก้ไขความขาดแคลนของ Solana ในเรื่องรากสถานะทั่วโลก ทำให้สามารถใช้คุณสมบัติสำคัญ เช่น พิสูจน์การรวมสำหรับพิสูจน์ข้อบกพร่อง การถอนทรัพย์อย่างปลอดภัย และการดำเนินการโดยไม่มีสถานะ

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

โดยใช้ Merkle Patricia Tries (MPT) สำหรับการจัดการสถานะ SOON จะสอดคล้องกับโครงสร้างพื้นฐานของ Ethereum โดยเสริมความสามารถในการทำงานร่วมกันและส่งเสริมการพัฒนาโซลูชัน L2 ที่ใช้ SVM นวัตกรรมนี้เสริมความแข็งแกร่งของระบบนิเวศ SVM โดยการปรับปรุงความปลอดภัย ความยืดหยุ่น และความเข้ากันได้ พร้อมสนับสนุนการเจริญของแอปพลิเคชันที่แบบกระจาย

ข้อปฏิเสธ:

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