BTC
ETH
HTX
SOL
BNB
ดูตลาด
简中
繁中
English
日本語
한국어
ภาษาไทย
Tiếng Việt

การวิจัย: โมเดลผู้ให้บริการของรัฐใน Ethereum 2.0

以太坊爱好者
特邀专栏作者
บทความนี้มีประมาณ 5623 คำ การอ่านทั้งหมดใช้เวลาประมาณ 9 นาที
มีตัวเลือกสถานะมากมาย
สรุปโดย AI
มีตัวเลือกสถานะมากมาย

หมายเหตุบรรณาธิการ: บทความนี้มาจากผู้ที่ชื่นชอบ Ethereum (ID: ethfans)หมายเหตุบรรณาธิการ: บทความนี้มาจาก

ผู้ที่ชื่นชอบ Ethereum (ID: ethfans)

การแนะนำ

ผู้เขียน: adietrichs แปลและพิสูจน์อักษร: Pei Qi & A Jian พิมพ์ซ้ำโดย Odaily โดยได้รับอนุญาต

บทความนี้ร่วมเขียนกับ samwilsn และ adietrichs โดยได้รับความช่วยเหลือเป็นอย่างดีจาก villanuevawill และทีม Quilt

การแนะนำ

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

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

เกณฑ์การเปรียบเทียบ

ข้อ จำกัด การเข้าถึงของรัฐ

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

หากโหมดจำกัดการเข้าถึงสถานะไดนามิก Eth1 มักจะล้มเหลวในการเป็น Eth2 Execution Environment (EE) และมักจะต้องการการจัดการพิเศษ

  • ชื่อเรื่องรอง

  • ค่าตอบแทนผู้ให้บริการของรัฐเปรียบเทียบใน 2 ลักษณะดังนี้

ใครเป็นคนจ่ายและคำนวณค่าชดเชยอย่างไร?

ผู้ให้บริการรัฐที่เห็นแก่ผู้อื่นได้รับการสนับสนุนในขั้นต้น และถ้าได้ สามารถเพิ่มสิ่งจูงใจในภายหลังได้หรือไม่

  • ชื่อเรื่องรอง

  • ความเสี่ยงจากการรวมศูนย์

  • ความเสี่ยงจากการรวมศูนย์จะแตกต่างกันไปในแต่ละรุ่น:

ใครสามารถตรวจสอบธุรกรรมได้บ้างและในระดับใด

ควรมีความไว้วางใจซึ่งกันและกันในระดับใดระหว่างผู้เสนอบล็อกและผู้ผลิตของรัฐ

ข้อ จำกัด ด้านเวลา

มีเวลาแน่นอนสำหรับผู้ผลิตบล็อกในการเผยแพร่บล็อก ดังนั้นเราจึงพิจารณาเป็นพิเศษว่าโหมดต่างๆ ทำงานอย่างไรภายในเวลาที่กำหนด

ชื่อเรื่องรอง

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

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

แบบอย่าง

ชื่อเรื่องรอง

รุ่นดันตรง

ข้อ จำกัด การเข้าถึงของรัฐ

ความตื่นเต้น

ผู้ใช้ที่สร้างธุรกรรมโดยพื้นฐานแล้วจะกลายเป็นผู้ให้บริการของรัฐเพียงรายเดียวสำหรับธุรกรรม โดยทั่วไปแล้ว ไม่มีทางที่จะรับประกันได้ว่าสถานะที่ผู้ใช้ให้ไว้จะสามารถตอบสนองความต้องการในการเข้าถึงทั้งหมดได้ เมื่อธุรกรรมอยู่บนเครือข่ายในอนาคต ดังนั้นในโหมด Direct Push จะสามารถดำเนินการได้เฉพาะธุรกรรมที่มีการเข้าถึงสถานะที่คาดการณ์ได้ เนื่องจากการทำธุรกรรมสามารถเข้าถึงได้โดยใช้สถานะคงที่เท่านั้น ผู้สร้างสัญญาควรออกแบบสัญญาของตนให้มีการเข้าถึงสถานะที่คาดเดาได้: สามารถใช้คำอธิบายประกอบ เช่น รายการการเข้าถึง โดยระบุรายละเอียดว่าสัญญาสามารถเข้าถึงตำแหน่งใดในระหว่างรันไทม์ แนวทางนี้เมื่อรวมกับรูปแบบที่หลีกเลี่ยงการเข้าถึงสถานะไดนามิก (ดูบล็อกโพสต์ที่เกี่ยวข้องนี้โดย Vitalik บน Eth1.x) ควรทำให้เกิดรูปแบบใหม่ที่ยังคงมีฟังก์ชันการทำงานเพียงพอ

อย่างไรก็ตาม นี่จะเป็นการออกจากระบบ Eth1 ในปัจจุบันอย่างมาก อาจทำให้แผนการแปลง Eth1 เป็น Eth2 เสียหายได้

ความตื่นเต้น

รูปแบบนี้อาศัยเครือข่ายผู้ให้บริการของรัฐทั่วไปเท่านั้น ตามที่ระบุไว้ข้างต้น ดูเหมือนว่าจะทำได้โดยไม่มีระบบจูงใจ

สามารถเพิ่มระบบ Incentive ผ่านช่องทางการชำระเงิน เนื่องจากผู้ใช้แต่ละรายต้องสร้างช่องทางการชำระเงินกับผู้ให้บริการของรัฐหนึ่งรายหรือมากกว่า วิธีการนี้ควรมีความซับซ้อนเป็นพิเศษ

ความเสี่ยงจากการรวมศูนย์

ผู้ให้บริการสถานะเดียวไม่สามารถเซ็นเซอร์ธุรกรรมได้ เนื่องจากผู้ใช้สามารถส่งคำถามหลายรายการไปยังผู้ให้บริการหลายสถานะได้

เนื่องจากผู้ให้บริการสถานะสามารถเก็บสถานะได้เพียงบางส่วนเท่านั้น ความต้องการด้านฮาร์ดแวร์จึงลดลงได้ตามต้องการ

สิ่งจูงใจทางการเงินอาจกระตุ้นให้ผู้ให้บริการของรัฐบางรายรวมศูนย์ ดังนั้นเมื่อผู้ใช้ซื้อรัฐผ่านช่องทางการชำระเงิน พวกเขาจำเป็นต้องไว้วางใจฝ่ายตรงข้าม

ข้อ จำกัด ด้านเวลา

ไม่มีข้อจำกัดด้านเวลา

  • การระบุแหล่งที่มาของรัฐที่สูญหาย

  • จุดสำคัญ

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

ข้อเสียเปรียบหลัก: เหมาะสำหรับการทำธุรกรรมที่ทราบความต้องการในการเข้าถึงสถานะทั้งหมดล่วงหน้าเท่านั้น ซึ่งจะจำกัดการทำงานของระบบทั้งหมด ปัญหาความเข้ากันได้ไม่สามารถแก้ไขได้ แม้ว่าจะมีการบรรเทาปัญหาบางอย่างให้ใช้งาน โดยเฉพาะอย่างยิ่งภายใต้โมเดลนี้ Eth1 ไม่สามารถกลายเป็นสภาพแวดล้อมการดำเนินงานของ Eth2 ได้

ชื่อเรื่องรอง

รุ่นพุชรีเลย์

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

ความตื่นเต้น

ข้อ จำกัด การเข้าถึงของรัฐ

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

  • ความตื่นเต้น

  • การออกแบบกลไกจูงใจสำหรับผู้ส่งต่อนั้นค่อนข้างซับซ้อน เนื่องจากเมื่อข้อมูลของรัฐและพยานเปิดเผยต่อสาธารณะแล้ว ผู้ใช้และ/หรือ BPs มีโอกาสเลี่ยงผ่านพยานและสร้างแพ็คเกจธุรกรรมขึ้นใหม่เอง

สองวิธีแก้ปัญหาที่เป็นไปได้:

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

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

  • ความเสี่ยงจากการรวมศูนย์

ความเสี่ยงของการรวมศูนย์ขึ้นอยู่กับสิ่งจูงใจของผู้ถ่ายทอดที่ใช้:

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

การใช้ช่วงเวลาพิเศษและกลุ่มธุรกรรมทำให้เกิดการกระจายอำนาจในระดับสูง แต่ด้วยความสะดวกสบายของผู้ใช้และการใช้งานกลุ่มธุรกรรมที่ซับซ้อนมากขึ้น ในทางทฤษฎี ผู้ใช้สามารถดึงแพ็คเกจธุรกรรมจากกลุ่มธุรกรรม เพิ่มธุรกรรมของตนเองเพื่อขยายแพ็คเกจธุรกรรม จากนั้นส่งต่อแพ็คเกจธุรกรรมด้วยค่าธรรมเนียมการทำธุรกรรมที่สูงขึ้น

ข้อ จำกัด ด้านเวลา

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

  • การระบุแหล่งที่มาของรัฐที่สูญหาย

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

  1. จุดสำคัญ

  2. ข้อได้เปรียบหลัก: ไม่มีข้อ จำกัด การเข้าถึงของรัฐ

  3. ข้อบกพร่อง:

  4. หากไม่มีกลุ่มธุรกรรม จะไม่สามารถรวมแพ็คเกจธุรกรรมได้ ดังนั้นบล็อกจึงสามารถมีได้เฉพาะแพ็คเกจธุรกรรมที่เสนอโดยผู้ถ่ายทอดรายเดียว ผู้ถ่ายทอดสามารถรวมศูนย์และแนะนำการเซ็นเซอร์

แม้จะมีกลุ่มธุรกรรม แต่ก็ไม่ชัดเจนว่าการรวมกันของชุดธุรกรรมจะเพียงพอที่จะบรรเทาปัญหาการเซ็นเซอร์ได้อย่างเต็มที่หรือไม่

ระบบแรงจูงใจมีความซับซ้อน

ชื่อเรื่องรอง

รุ่นดึง (รุ่นดึง)

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

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

หรือสามารถใช้ Value-Holding EE (VHEE) ได้ ทุกธุรกรรมใช้ VHEE นี้เพื่อชำระค่าธรรมเนียม โหนดในเครือข่ายจะเข้าใจ VHEE เพื่อให้สามารถตรวจสอบความถูกต้องของธุรกรรมได้

ในทั้งสองกรณี โหนดในเครือข่ายจำเป็นต้องอัปเดตข้อมูลพยานของสถานะที่แนบเมื่อบล็อกใหม่มาถึง

ข้อ จำกัด การเข้าถึงของรัฐ

ความตื่นเต้น

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

เนื่องจากผู้ใช้ต้องระบุสถานะของการตรวจสอบลายเซ็นและความสามารถในการชำระค่าธรรมเนียม ในทางเทคนิคแล้ว ข้อจำกัดในส่วนของการทำธุรกรรมจะเหมือนกับที่ระบุไว้ในโมเดล Direct Push อย่างไรก็ตาม ข้อจำกัดเหล่านี้ไม่มีนัยสำคัญในทางปฏิบัติ เนื่องจากใน Eth1 การตรวจสอบลายเซ็นและการชำระค่าธรรมเนียมเป็นการเข้าถึงสถานะที่คาดเดาได้ ความเข้ากันได้ระหว่าง Eth1 และ Eth2 จะไม่ถูกทำลาย นอกจากนี้ สำหรับ VHEE การออกแบบช่วยให้มั่นใจได้ถึงการเข้าถึงสถานะที่คาดเดาได้ ทำให้ไม่จำเป็นต้องมีข้อจำกัดเพิ่มเติม

ความตื่นเต้น

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

ความเสี่ยงจากการรวมศูนย์

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

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

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

ข้อ จำกัด ด้านเวลา

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

  • การระบุแหล่งที่มาของรัฐที่สูญหาย

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

จุดสำคัญ

ข้อได้เปรียบ:

  • ไม่มีข้อ จำกัด การเข้าถึงของรัฐที่เกี่ยวข้อง

มีปัญหาข้อจำกัดด้านเวลาน้อยลง

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

ข้อเสียเปรียบหลัก: ต้องมีการกำหนดมาตรฐานบางอย่างในการตรวจสอบลายเซ็น ไม่ว่าจะผ่านสคริปต์การตรวจสอบหรือใช้ VHEE

การอภิปรายเพิ่มเติม

ข้อมูลรับรองการพึ่งพาตนเองและค่าน้ำมัน

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

ค่าธรรมเนียมของรัฐ

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

ราคาคำนวณตามจำนวนการเข้าชมสถานะหรือไม่? หรือคิดตามขนาดของข้อมูลพยาน?

หากค่าใช้จ่ายขึ้นอยู่กับปริมาณข้อมูลของข้อมูลพยาน BP รู้ได้อย่างไรว่า SP ไม่มีไบต์พิเศษ

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

นามธรรมของรัฐ

ETH
ยินดีต้อนรับเข้าร่วมชุมชนทางการของ Odaily
กลุ่มสมาชิก:
https://t.me/Odaily_News
กลุ่มสนทนา:
https://t.me/Odaily_GoldenApe
บัญชีทางการ:
https://twitter.com/OdailyChina
สารบัญบทความ
คลังบทความของผู้เขียน
以太坊爱好者
อันดับบทความร้อน
Daily
Weekly
ดาวน์โหลดแอพ Odaily พลาเน็ตเดลี่
ให้คนบางกลุ่มเข้าใจ Web3.0 ก่อน
IOS
Android