เครือข่ายรีเลย์และกลไกค่าธรรมเนียมของ Eth2.0
หมายเหตุบรรณาธิการ: บทความนี้มาจากผู้ที่ชื่นชอบ Ethereum (ID: ethfans), ผู้แต่ง: John Adler, ผู้แปล & ผู้พิสูจน์อักษร: IAN LIU & A Jian, ทำซ้ำโดย Odaily โดยได้รับอนุญาต
พื้นหลัง
พื้นหลัง
ก่อนที่จะดำดิ่งลงไปในเครือข่ายรีเลย์ เรามาทบทวนปัญหาคอขวดหลักข้อหนึ่งของ Ethereum (หรือขาดไป) ได้แก่ สถานะ
ใน Ethereum รัฐหมายถึงการรวบรวมยอดเงินในบัญชี รหัสสัญญา และเนื้อหาการจัดเก็บสัญญา (ใน Bitcoin รัฐหมายถึงการรวบรวม UTXO) เมื่อใดก็ตามที่ดำเนินการธุรกรรม สถานะ (ข้อมูลที่ไม่สามารถบีบอัดได้ประมาณ 45 GB) จะถูกอ่านและเขียน ก่อนหน้านี้ ผู้คนต่างตั้งคำถามถึงความสามารถในการปรับขนาดไม่ได้ของโมเดลการคำนวณ Ethereum แต่ในปัจจุบัน การอ่านและเขียนของรัฐได้กลายเป็นคอขวดของต้นทุนในการดำเนินการธุรกรรม และประสิทธิภาพ I/O ของดิสก์กลายเป็นคอขวดสำหรับการรัน เครือข่าย Ethereum เต็มรูปแบบ ข้อ จำกัด ของโหนด
โปรดทราบว่าเพื่อให้สามารถดำเนินการธุรกรรมใดๆ ตามกระบวนทัศน์แบบเก็บสถานะ (stateful paradigm) ได้ โหนดแบบเต็มจะต้องตรวจสอบให้แน่ใจว่าสถานะทั้งหมดอยู่ในตำแหน่งที่สามารถเข้าถึงได้เสมอ (เช่น หน่วยความจำ พื้นที่สว็อป) หากนำไปใช้กับสถานการณ์บล็อกเชนเดียว สิ่งนี้อาจยอมรับได้ยาก แต่เมื่อต้องเผชิญกับการแยกส่วนและการปรับโครงสร้างองค์กรของคณะกรรมการเกี่ยวกับการแยกส่วน ข้อกำหนดนี้ไม่มีเหตุผลอย่างยิ่ง ลองนึกภาพว่าทุกครั้งที่ผู้ตรวจสอบถูกกำหนดให้กับ shard chain เขาจะต้องซิงโครไนซ์สถานะทั้งหมดบน shard จากนั้นระบบนี้จะเทียบเท่ากับ blockchain เดียว ยกเว้นว่าขนาดบล็อกในขณะนี้จะเท่ากับขนาด shard block * จำนวนเศษ
ชื่อเรื่องรอง
การแบ่งส่วนและไคลเอนต์ไร้สัญชาติ
ในกระบวนทัศน์ไคลเอนต์ไร้สัญชาติ (เดิมเรียกว่า "ไร้ที่เก็บข้อมูล") ผู้ตรวจสอบความถูกต้องจำเป็นต้องจัดเก็บตารางสถานะบล็อกเชนที่ถูกบีบอัด (มักเรียกว่าตัวสะสม) ซึ่งช่วยลดภาระในการดำเนินการธุรกรรมได้อย่างมาก โดยปกติขนาดของตัวสะสมจะเป็นค่าคงที่ (เช่น: ค่ารากของต้นไม้ Merkle ของรัฐ) แต่ก็อาจมีขนาดเป็นลอการิทึมด้วย
สาระสำคัญของลูกค้าไร้สัญชาติคือการทำธุรกรรมแต่ละครั้งจะมาพร้อมกับข้อมูลพยาน (พยาน) ของเครื่องสะสมปัจจุบันซึ่งมีข้อมูลทั้งหมดที่จำเป็นในการทำธุรกรรม ใน Ethereum การใช้ Sparse Merkle Tree (SMT, Sparse Merkle Tree) เป็นตัวสะสม องค์ประกอบสถานะทั้งหมดที่เกี่ยวข้องในธุรกรรมสามารถรวมอยู่ในสาขา Merkle tree
ในแอปพลิเคชันอื่นๆ ไคลเอนต์ไร้สัญชาติสามารถลดระยะเวลาการซิงโครไนซ์เริ่มต้นของโหนด Ethereum ซึ่งเป็นหลักการของ Beam Sync
ข้อสังเกต: มี cryptographic accumulators บางตัว (เช่น RSA accumulators) ที่ทำงานได้ดีกว่า Merkle แต่ accumulators ดังกล่าวต้องการการกำหนดค่าเริ่มต้นที่เชื่อถือได้หรือใช้เทคนิคการเข้ารหัสที่ทันสมัยที่ไม่ได้รับการยืนยัน ดังนั้น จึงไม่ปลอดภัยที่จะนำไปใช้ในระบบการผลิต มันจะ ใช้เวลาสักครู่
แต่ลูกค้าไร้สัญชาติมีความท้าทายของตัวเอง: เมื่อใช้ Merkle accumulator พยานจะหมดอายุทุกครั้งที่การดำเนินการเต็มรูปแบบสิ้นสุดลง หากแบบจำลองกำหนดให้ธุรกรรมแต่ละรายการมีพยานแยกต่างหาก จากนั้นดำเนินธุรกรรมเหล่านี้ตามลำดับ ข้อมูลพยานของธุรกรรมในภายหลังจะล้าสมัย และต้องสามารถอัปเดตพยานของตนเองได้เมื่อธุรกรรมก่อนหน้าแต่ละรายการเสร็จสมบูรณ์ โชคดีที่การอัปเดตพยานของตัวสะสม Merkle เหล่านี้เกี่ยวข้องกับวิธีการโอเวอร์เฮดแบบไม่มีแฮช - หากสามารถเพิ่มข้อมูลพยานเป็นส่วนต่อท้ายของการทำธุรกรรม "กระเป๋าใบใหญ่" ก็ไม่จำเป็นต้องอัปเดตพยานบุคคลของแต่ละธุรกรรม หรือสามารถรวมเข้ากับการพิสูจน์หลายรายการ (multiproof)
หากผู้ใช้ทั้งหมดดูแลโหนดทั้งหมดและอัปเดตสถานะพยานตามเวลาจริง ระบบไคลเอนต์ไร้สถานะจะถูกนำมาใช้ทันที น่าเสียดายที่ในสภาพแวดล้อมแบบ sharded หมายความว่าผู้ใช้ทุกคนจะต้องรักษาสถานะทั้งหมดบน shard ของตนเอง ซึ่งไม่เพียงแต่ทำไม่ได้จริงเท่านั้น .
เพื่อแก้ปัญหานี้ แนวคิดของรีเลย์ (หรือที่เรียกว่าผู้ให้บริการของรัฐ) ได้รับการแนะนำที่นี่ ผู้ส่งต่อมีหน้าที่จัดหาพยานตามที่ผู้ใช้ต้องการ และเรียกเก็บเงินจากผู้ใช้สำหรับบริการ ผู้ส่งต่อสามารถมุ่งเน้นบริการในชาร์ดเดียว ซึ่งแตกต่างจากผู้ใช้ อย่างไรก็ตาม ผู้ถ่ายทอดไม่สามารถคาดเดาได้ว่าผู้ใช้ต้องการสถานะเมื่อใด ดังนั้นพวกเขาจึงต้องตรวจสอบให้แน่ใจว่าพยานได้รับการอัปเดตทันเวลา นั่นคือสถานะการจัดเก็บข้อมูลตามเวลาจริง (เรียกว่าผู้ให้บริการสถานะ) สำหรับผู้ใช้ ที่จะได้รับ.
ชื่อเรื่องรอง
ข้อเสนอเครือข่ายรีเลย์และตลาดค่าธรรมเนียม
พื้นที่การออกแบบของ Ethereum 2.0 Phase 2 มีขนาดใหญ่มาก และมีข้อเสนอมากมายสำหรับโหมดการดำเนินการ ข้อเสนอแต่ละข้อแสดงวิธีการถ่ายโอนธุรกรรมระหว่างผู้ใช้และผู้เสนอบล็อกได้ดีขึ้นผ่านการชำระเงิน รวมกับกลไกเครือข่ายรีเลย์ บทนี้จะสรุปโปรโตคอลต่างๆ อย่างกระชับและครอบคลุมที่สุดเท่าที่จะเป็นไปได้ และมุ่งเน้นไปที่การวิเคราะห์ความเหมือนและความแตกต่างในเครือข่ายรีเลย์และกลไกค่าธรรมเนียม
ข้อเสนอตัวรวบรวม (เลิกใช้แล้ว)
นี่เป็นข้อเสนอช่วงต้นของเฟส 2 ซึ่งแบ่งองค์ประกอบการสร้างของเชนชาร์ดออกเป็นสามส่วน ได้แก่ ผู้เสนอ ผู้รวบรวม และผู้ดำเนินการ ผู้เสนอบางรายมีหน้าที่รับผิดชอบในการรวบรวมธุรกรรมและบรรจุลงในบล็อก (เรียกอีกอย่างว่าการเปรียบเทียบ) ผู้เสนอบางรายมีหน้าที่รับผิดชอบในการส่งการเรียงไปยังห่วงโซ่ (เปลี่ยนให้เป็นบล็อก) และสุดท้าย ผู้ดำเนินการจะให้สถานะใหม่ตามการเรียงที่เสนอ .
ยังไม่มีการศึกษาข้อเสนอนี้อย่างถ่องแท้จึงไม่มีการศึกษากลไกการชำระค่าธรรมเนียมด้วย นอกเหนือจากปัจจัยอื่นๆ ข้อเสนอนี้ถูกละทิ้งเนื่องจากกลไกจูงใจกระตุ้นให้ผู้ใช้กลายเป็นผู้เสนอ ผู้ประนีประนอม และผู้ดำเนินการในเวลาเดียวกันเพื่อให้เกิดประโยชน์สูงสุด
Phase 1 and Done
Casey Detrio เน้นย้ำในโพสต์บล็อกผู้บุกเบิกของเขา "เฟส 1 และเสร็จสิ้น: Data Availability Engine-Ethereum 2.0": ในระยะที่ 1 สามารถเพิ่มชิ้นส่วนการดำเนินการให้น้อยที่สุดเท่าที่จะเป็นไปได้เพื่อเชื่อมข้อมูลโดยไม่ต้องใช้การแยกส่วนของรัฐ ชิ้น ในรูปแบบนี้ Shards สามารถทำสองสิ่ง: 1) ตรวจสอบความถูกต้องของข้อมูล (เช่น ใส่ชุดของธุรกรรมลงในโครงสร้างข้อมูลที่รู้จัก เช่น Merkle tree) 2) ดำเนินการแบบไร้สัญชาติอย่างง่าย เช่น การตรวจสอบการพิสูจน์ด้วยความรู้เป็นศูนย์สำหรับข้อมูลที่ถูกลงโทษ
ตัวจัดการบล็อกข้อมูลสามารถกำหนดได้โดยการอัปโหลดสัญญาไปยัง beacon chain (สัญญาจะถูกแปลงเป็น "พรีคอมไพล์" ในอนาคต จากนั้นจึงกลายเป็น "สภาพแวดล้อมการดำเนินการ") รูปแบบของสัญญาอาจเป็นรหัสไบต์ที่สามารถ ลูกค้าจะแยกวิเคราะห์ขึ้นอยู่กับเนื้อหาของโปรโตคอลทั้งหมด
"ขั้นตอนที่ 1 และเสร็จสิ้น" หลีกเลี่ยงคำถามส่วนใหญ่เกี่ยวกับกลไกการชำระค่าธรรมเนียม เนื่องจากปัญหากลไกการชำระเงินมีอยู่ในข้อเสนอก่อนหน้านี้ และจะยังคงมีอยู่ ดังนั้นข้อเสนอจึงพยายามกำหนดให้เป็นกระบวนการที่ทำให้ Eth2.0 แทน ใช้งานได้นาน มีการเปลี่ยนแปลงเล็กน้อยและหวังว่าจะทราบในไม่ช้า ข้อเสนอแนะอีกประการหนึ่งคือการชำระค่าธรรมเนียมผ่านสัญญาบน Ethereum 1.x (ผู้เสนอบล็อกจัดเตรียมบล็อกข้อมูลที่ประมวลผลและพร้อมใช้งานบน Ethereum 2.0 จากนั้นเราจะจ่ายให้กับผู้เสนอ) อย่างไรก็ตาม นี่เป็นเรื่องน่าสงสัยเนื่องจากจะทำให้ความสามารถในการใช้งานของ Ethereum 2.0 ขึ้นอยู่กับอย่างมาก บน Ethereum 1.x
Phase 2 Proposal 1
หลังจากการวิจัยของ Detrio Vitalik Buterin ได้เสนอข้อเสนอใหม่ที่เฉพาะเจาะจงสำหรับเฟส 2: ข้อเสนอเฟส 2 1 ในข้อเสนอนี้ สคริปต์การดำเนินการ (แต่เดิมเรียกว่า "สัญญาลูกโซ่บีคอน") จะถูกจัดเก็บไว้ในลูกโซ่บีคอน และสามารถฝาก ETH ไว้ในสคริปต์การดำเนินการ (เพื่อชำระค่าธรรมเนียม) และจะไม่ออกจากลูกโซ่บีคอน สถานะและการดำเนินการของแต่ละส่วนนั้นเป็นอิสระจากกันโดยสิ้นเชิง
โปรดทราบว่าชื่ออาจทำให้เข้าใจผิดได้ สคริปต์การดำเนินการเป็นกฎที่กำหนดเครื่องเสมือนที่ดำเนินการธุรกรรม ไม่ใช่สัญญาอัจฉริยะที่เราเห็นใน Ethereum ในปัจจุบัน สคริปต์การดำเนินการต้องกำหนดโมเดลข้อมูลและรหัส opcodes ในลักษณะที่ไคลเอนต์สามารถแยกวิเคราะห์ วัด และเข้ารหัส (เช่น รหัส ewasm)
ในการชำระค่าธรรมเนียม สคริปต์การดำเนินการแต่ละรายการโดยพื้นฐานแล้วเป็นระบบเลเยอร์ 2 และผู้ตรวจสอบไม่สามารถ "รู้" กลไกการชำระเงินภายในได้ นี่ไม่ใช่ข้อบกพร่องของการออกแบบ แต่เป็นการจงใจ หากผู้ตรวจสอบชิ้นส่วนจำเป็นต้องแยกวิเคราะห์และคำนวณกลไกค่าธรรมเนียมต่างๆ (ซึ่งอาจเกี่ยวข้องกับสกุลเงินที่แตกต่างกัน) สิ่งนี้จะนำไปสู่การเพิ่มขึ้นอย่างมากในความยากของการใช้งานและความซับซ้อนของกลไกทางเศรษฐกิจอย่างไม่ต้องสงสัย นำเสนอจุดอ่อนเพิ่มเติมที่สามารถใช้ประโยชน์ได้ หรือแม้แต่ทำให้ใช้งานไม่ได้โดยสิ้นเชิง ในระดับใหญ่ ข้อโต้แย้งที่ต่อต้าน "สิ่งที่เป็นนามธรรมทางเศรษฐกิจ" ยังสามารถนำมาใช้กับรูปแบบการดำเนินการประเภทนี้ที่กำหนดประเภทของค่าธรรมเนียมตามสคริปต์ (หมายเหตุของผู้แปล: "สิ่งที่เป็นนามธรรมทางเศรษฐกิจ" เรียกอีกอย่างว่า "การกำหนดลักษณะทั่วไปของค่าธรรมเนียม" ใน The เลเยอร์โปรโตคอลรองรับผู้ใช้และผู้ตรวจสอบเพื่อปรับแต่งโทเค็นที่จะใช้เพื่อชำระค่าธรรมเนียมการจัดการ บางคนคิดว่าสิ่งนี้จะทำให้โทเค็นดั้งเดิมสูญเสียคุณค่า)
เนื่องจากตัวตรวจสอบไม่สามารถเก็บค่าธรรมเนียมโดยตรงจากการดำเนินการสคริปต์ พวกเขาจึงต้องได้รับค่าบริการด้วยวิธีอื่น สิ่งนี้ทำได้ด้วยสคริปต์การดำเนินการแบบพิเศษ (เช่น ชนิดที่ประดิษฐานอยู่) ทุกคนสามารถส่งธุรกรรมที่มีตรรกะต่อไปนี้: "หากข้อมูลนี้ที่ใช้สคริปต์การดำเนินการบางอย่างถูกบรรจุในช่วงเวลาหนึ่งๆ ในชาร์ดหนึ่งๆ ฉันจะจ่ายให้ ค่าธรรมเนียมให้กับบุคคลที่บันทึกบล็อกข้อมูลนี้" การดำเนินการทั้งหมดที่นี่ดำเนินการโดยผู้ส่งต่อ (หรือที่เรียกว่าผู้ดำเนินการ): ผู้ส่งต่อมีหน้าที่รับผิดชอบในการรวบรวมธุรกรรมของผู้ใช้ ซึ่งระบุไว้ตามสคริปต์การดำเนินการทั่วไปที่ไม่ได้ประดิษฐานไว้ ค่าธรรมเนียมจะถูกเรียกเก็บตาม กฎ จากนั้นผู้เสนอบล็อก (ตัวสร้าง) ในส่วนแบ่งจะได้รับการชำระเงินสำหรับธุรกรรมที่บรรจุตามสคริปต์การดำเนินการที่ตั้งไว้
บล็อกของ William Villanueva การเดินทางผ่านเฟส 2 ของ Ethereum 2.0 ให้บทสรุปที่สมบูรณ์แบบของข้อเสนอเฟส 2 จนถึงตอนนี้
Phase 2 Proposal 2
ได้รับแรงบันดาลใจจากงานก่อนหน้าของ Detrio V God ได้เสนอข้อเสนอเฟส 2 2 อีกครั้ง โดยมีเป้าหมายเพื่อลดความซับซ้อนของข้อเสนอ 1 ลบสถานะบนชาร์ดเชน และใช้บีคอนเชนเพื่อติดตามชาร์ดต่างๆ และสภาพแวดล้อมการดำเนินการ (Execution Environment, EE เดิมเรียกว่า Execution Script) รูทสถานะที่แตกต่างกัน
ข้อดีของการออกแบบนี้คือสภาพแวดล้อมการดำเนินการที่แตกต่างกันสามารถเลือกตัวสะสมของตนเองได้ (เช่น: Merkle tree ที่กระจัดกระจาย, ต้นไม้สีแดง-ดำ, ตัวสะสมการเข้ารหัส ฯลฯ) ซึ่งแตกต่างจากข้อเสนอก่อนหน้านี้ซึ่งต้องเคารพ (ประดิษฐาน) รูปแบบของตัวสะสม .
ขั้นตอนการทำธุรกรรมทั่วไปมีดังนี้: ผู้ใช้สร้างธุรกรรมและส่งไปยังผู้ส่งต่อซึ่งเพิ่มพยาน (ในรูปแบบของสาขา Merkle หากใช้ Merkle accumulators) เนื่องจากผู้ใช้จำเป็นต้องได้รับเงินจากผู้ใช้ จากนั้นผู้ส่งต่อจะบรรจุธุรกรรมหลายรายการและส่งไปยังผู้เสนอบล็อกพร้อมกัน และชำระเงินผ่านกลไกในตัวของโปรโตคอล ทำให้ผู้เสนอสามารถบรรจุชุดของธุรกรรมลงในบล็อก (ชาร์ด) ถัดไป เช่นเดียวกับข้อเสนอที่ 1 "กลไกที่สร้างขึ้นในโปรโตคอล" ที่นี่หมายถึง EE ที่สูงกว่า (EE ที่ประดิษฐานอยู่) ซึ่งผู้ตรวจสอบทั้งหมดสามารถรับรู้ได้
สำหรับผู้ตรวจสอบ แผนการนี้ช่วยลดภาระได้ในระดับหนึ่ง แต่เนื่องจากการดำเนินการข้างต้นยังคงต้องการสถานะการแบ่งส่วน และข้อเสนอไม่ได้ออกแบบกลไกการชำระค่าธรรมเนียมในโปรโตคอลระหว่างผู้ใช้และผู้ส่งต่อ จึงยังไม่ได้รับการแก้ไขทั้งหมด ปัญหาเกี่ยวกับเครือข่ายรีเลย์ ประการแรก การใช้วิธีการภายนอกโปรโตคอลในการชำระเงินทำให้ความเป็นส่วนตัวของผู้ใช้อ่อนแอลง ประการที่สอง ยังไม่ชัดเจนว่าจะสร้างระบบออฟไลน์ทั้งหมดได้อย่างไร -hand เงินจะถูกส่งในมือเดียว (นั่นคือ atomicity ของการทำธุรกรรม) ประการที่สาม ความเสี่ยงสูงที่อาจเกิดขึ้นจากการใช้วิธีการนอกข้อตกลงในการชำระเงิน และพลังการประมวลผลสูงที่จำเป็นในการเป็นผู้ส่งต่อ (เพราะถ้า ผู้ถ่ายทอดต้องการให้บริการ EE หรือชิ้นส่วน ต้องจัดเก็บสถานะทั้งหมดเพื่อให้สามารถสร้างพยานได้) อาจนำไปสู่ปัญหาการรวมศูนย์ - ในกรณีที่เลวร้ายที่สุด อาจมีรีเลย์ "gatekeeper" เหลืออยู่ไม่กี่ตัวระหว่าง ผู้ใช้และเครือข่าย Ethereum 2.0 By.
กลับสู่โหมดพูลบัฟเฟอร์ธุรกรรม
Vitalik กล่าวถึงในข้อเสนอใหม่ว่าการอนุญาตให้ผู้ส่งต่อสามารถจ่ายเงินให้กับผู้เสนอแบบบล็อกอย่างมีเงื่อนไขได้นั้นต้องใช้วิธีผูกมัดสองครั้งอย่างหนักเพื่อให้แน่ใจถึงปรมาณูของการชำระเงิน ดังนั้น จึงเป็นการดีกว่าที่จะใช้ EE ตลาดที่มีค่าธรรมเนียมเพื่อแก้ปัญหาทั้งหมด ในข้อเสนอนี้ EE จะมีความสมดุลของตัวเอง หลังจากที่ EE ดำเนินการธุรกรรมชุดหนึ่งแล้ว ระบบจะออกใบเสร็จรับเงิน และ EE ระดับสูง (EE ที่ประดิษฐานอยู่) ที่รับผิดชอบในการชำระค่าธรรมเนียมจะโอน Ethereum จากบัญชี EE ไปยังผู้เสนอบล็อกตามข้อมูลนี้ ดังนั้น ยิ่ง EE จ่ายค่าธรรมเนียมมากเท่าไหร่ ก็สามารถ "ย้อนดู" ใบเสร็จก่อนหน้าและดำเนินการโอนได้ การเติมเงินในบัญชี EE อาจเป็นความรับผิดชอบของผู้ส่งต่อ (หรือผู้มีส่วนได้ส่วนเสียอื่นๆ)
ข้อดีของข้อเสนอนี้คือไม่จำเป็นต้องใช้วิธีการที่ซับซ้อนใดๆ ในการประสานงานการชำระเงินระหว่างผู้ส่งต่อและผู้เสนอบล็อก แต่ไม่ได้ระบุว่าผู้ใช้ควรโต้ตอบกับผู้ส่งต่ออย่างไร แต่แนะนำให้ใช้ช่องทางการชำระเงินเท่านั้น .
จากข้อเสนอเดิม Villanueva แนะนำให้กลับไปใช้โมเดลบัฟเฟอร์พูลของธุรกรรม ในกรณีนี้ ผู้ส่งต่อจำเป็นต้องทำหน้าที่เป็นผู้ให้บริการของรัฐเท่านั้น โดยจัดหาพยานเท่านั้นโดยไม่ต้องบรรจุธุรกรรม ผู้เสนอบล็อก (หรือโดยทั่วไปคือผู้ตรวจสอบความถูกต้องของชิ้นส่วน) จะเก็บบัฟเฟอร์พูล และข้อมูลพยานที่จำเป็นเพื่อจัดแพคเกจธุรกรรม เนื่องจาก EE แต่ละคนสามารถเลือกตัวสะสมที่แตกต่างกันได้ EE จึงต้องประกาศวิธีการที่แน่นอนในการรวมพยานล่วงหน้า เพื่อให้ผู้เสนอบล็อกสามารถรวมพยานสองคนขึ้นไปได้ เช่น การรวมสาขาของ Merkle หลายสาขาเข้าเป็น Merkle หลายรายการ
เนื่องจากผู้ให้บริการของรัฐต้องการเพียงแค่ให้พยาน (โดยปกติจะอยู่ในรูปแบบของสาขาของ Merkle) บทบาทจำนวนมากจึงพร้อมใช้งานสำหรับงานนี้: ตัวอย่างเช่น เซิร์ฟเวอร์ไคลเอ็นต์แบบไลท์ เซิร์ฟเวอร์ไคลเอ็นต์แบบไลท์สามารถจูงใจให้พยานได้รับเครื่องมือที่สะดวกมากขึ้นและต้นทุนที่ต่ำลง ซึ่งสามารถช่วยให้มีความน่าเชื่อถือสูงได้ ถึงกระนั้นก็เป็นเรื่องน่าปวดหัวสำหรับผู้ใช้ที่จะต้องจ่ายเงินให้กับผู้ให้บริการของรัฐโดยใช้ช่องทางการชำระเงินที่มีอุปสรรคสูง
ระยะที่ 2 สถาปัตยกรรมทางเลือก
ไม่นานมานี้ Vitalik ได้เสนอสถาปัตยกรรมทางเลือกเฟส 2 โดยตั้งใจที่จะลบสถานะของการแบ่งชิ้นส่วนออกไปโดยสิ้นเชิง ประเด็นสำคัญคือเอ็นจิ้นการเปลี่ยนสถานะที่สมบูรณ์ มีสถานะ และแสดงออกอย่างชัดเจน (เช่น EVM) จะถูกเพิ่มเข้าไปในบีคอนเชน เอ็นจิ้นนี้ทำหน้าที่เป็น "ตัวจัดกำหนดการ" ที่คอยติดตามสถานะรูทของ EE การออกแบบตัวกำหนดตารางเวลายังเปิดใช้งานการดำเนินการธุรกรรมแบบหลายส่วนย่อย: ตรวจสอบส่วนย่อยและช่องเวลาตามลำดับที่กำหนดไว้ล่วงหน้าเพื่อให้แน่ใจว่าธุรกรรมหลายรายการข้ามส่วนย่อยไปยัง EE เดียวกันนั้นดำเนินการอย่างถูกต้อง (โดยการตรวจสอบสถานะก่อนการดำเนินการและสถานะรากของสถานะหลังการดำเนินการ โดยไม่สนใจชาร์ดบล็อกที่ไม่ถูกต้องหรือไม่อยู่ในลำดับ)
กลไกการชำระค่าธรรมเนียมของข้อเสนอนี้ไม่เปลี่ยนแปลงจากข้อเสนอก่อนหน้า แต่เนื่องจากผู้มอบหมายงานมีความสามารถเพียงพอที่จะจัดการการจัดการยอดคงเหลือ EE และการใช้ใบเสร็จรับเงิน จึงไม่จำเป็นต้องมีค่าธรรมเนียมการชำระเงิน EE เฉพาะอีกต่อไป
ข้อเสนอการลดความซับซ้อนของ Shard Chain
ในการประชุม DevCon 5 Vitalik ได้ประกาศการปรับโครงสร้างครั้งใหญ่ของสถาปัตยกรรม Ethereum 2.0 ซึ่งได้รับแรงบันดาลใจจากการออกแบบของ Near protocol's sharding block - Nightshade ในข้อเสนอใหม่ แทนที่จะกำหนดให้เชนชาร์ดแต่ละอันรันกฎการเลือกทางแยกอิสระ บล็อกและครอสลิงค์จะถูกอินเตอร์ลีฟเพื่อสร้างบล็อกและครอสลิงค์ในอัตราที่เร็วขึ้น บล็อกในชาร์ดตามบล็อกเชนบีคอนจะถูกสร้างขึ้นพร้อมกัน และชาร์ดทั้งหมดจะไขว้กัน ต่อกับบล็อกโซ่บีคอนทุกอัน (ภายใต้สถานการณ์ปกติ) สถาปัตยกรรมเพิ่มจำนวนของ shard cross-links เพื่อตอบสนองต่อจำนวนของ cross-links ที่เพิ่มขึ้น จำนวนของ shard จะลดลงจาก 1024 เป็น 64 ในขณะเดียวกันปริมาณงานของแต่ละ shard ก็เพิ่มขึ้นด้วย ทำให้ ทรูพุตของวอลุ่มระบบทั้งหมดยังคงอยู่ในระดับเดิม
การเปลี่ยนแปลงพื้นฐานในโหมดการคิดที่กล่าวถึงข้างต้นทำให้ตลาดค่าธรรมเนียมง่ายขึ้น: เนื่องจากจำนวนของชาร์ดลดลงอย่างมาก การสื่อสารข้ามชาร์ดจึงง่ายขึ้น และผู้ใช้สามารถจัดเก็บ Ether โดยตรงในแต่ละชาร์ดและเสนอการชำระเงินบล็อคโดยตรงโดยผู้รับ ( อีกครั้งผ่านข้อเสนอข้างต้นเพื่อออกใบเสร็จรับเงินผ่าน EE)
ชื่อเรื่องรอง
เตือน
การอภิปรายข้างต้นเกี่ยวกับเครือข่ายรีเลย์/ตลาดค่าธรรมเนียมใน Ethereum 2.0 ยังไม่ครอบคลุมทั้งหมด:
สำหรับผู้ใช้ ผู้ส่งต่อ และผู้เสนอบล็อก ทุกคนต้องการสิ่งจูงใจและบริการการชำระเงินที่เหมาะสม ผู้ใช้สามารถรับพยานที่ต้องการได้โดยการจ่ายเงิน ผู้ส่งต่อจะเรียกเก็บค่าธรรมเนียมเพื่อให้พยาน และผู้เสนอบล็อกจะเรียกเก็บค่าธรรมเนียมในการทำธุรกรรมแพ็คเกจ วิธีที่ผู้ส่งต่อจ่ายให้กับผู้เสนอบล็อก (หรือทางอ้อมผ่าน EE) สามารถประกาศได้ในข้อตกลง แต่ผู้ใช้ต้องการรับข้อมูลพยานในขณะที่ต้องแน่ใจว่าธุรกรรมได้รับการบรรจุหีบห่อ และวิธีการชำระเงินนั้นไม่ง่ายนัก
สำหรับผู้ใช้ วิธีการชำระเงินที่ดีควรเป็นแบบแรงเสียดทานต่ำ ทำให้ผู้ใช้สลับไปมาระหว่างรีเลย์ต่างๆ ได้ง่าย อย่างไรก็ตาม ขึ้นอยู่กับช่องทางการชำระเงินของ blockchain ภายนอก มีค่ามัดจำการชำระเงินล่วงหน้าและข้อกำหนดสำหรับความมีชีวิตชีวาของ chain ภายนอก โดยหลักแล้ว ปัญหาการชำระเงินของผู้ใช้สามารถแก้ไขได้ภายในข้อตกลง
ต่อจากข้อที่แล้ว น่าจะทำให้ผู้ส่งต่อเซ็นเซอร์ผู้ใช้ได้ยากขึ้น น่าเสียดายที่พยานถูกดึงมาจากรายการการเข้าถึงที่ฝังไว้ ดังนั้นจึงไม่มีวิธีใดที่จะป้องกันไม่ให้ผู้ถ่ายทอดถูกขึ้นบัญชีดำ
ผู้ตรวจสอบความถูกต้องไม่จำเป็นต้อง "เข้าใจ" วิธีการชำระเงินในแต่ละ EE เนื่องจากวิธีนี้จะซับซ้อนอย่างยิ่งและเป็นอุปสรรคอย่างมากในการปรับใช้และการสร้างตลาดที่มีประสิทธิภาพ
ผู้ใช้ไม่จำเป็นต้องดูแลรักษาโหนดทั้งหมด (เช่น ไม่จำเป็นต้องรักษาพยานที่ต้องการ) เราต้องการให้ข้อเสนอนี้เป็นมิตรกับลูกค้ารายย่อย
สรุป
สรุป
เมื่อมองย้อนกลับไปในปีที่ผ่านมา มีการดำเนินการซ้ำหลายครั้งเกี่ยวกับการวิจัยเกี่ยวกับเครือข่ายรีเลย์และตลาดค่าธรรมเนียม เรามุ่งมั่นที่จะนำประสบการณ์ผู้ใช้ที่ดีมาสู่ผู้ใช้และโหนดแสง ในขณะที่ลดภาระของผู้ตรวจสอบและรับประกันการเข้าถึงฟรี เข้าถึงเพศได้มากที่สุด มองไปข้างหน้า เราหวังว่าจะได้เห็นข้อเสนอเพิ่มเติมสำหรับเฟส 2 การปรับปรุงเพิ่มเติมและทำให้ทุกด้านของ Ethereum 2.0 สมบูรณ์แบบยิ่งขึ้น!
หมายเหตุ: ลิงก์ไปยังข้อความต้นฉบับ:https://medium.com/
