ค่าธรรมเนียมการทำธุรกรรมของรีเลย์เชนและขีดจำกัดการทำธุรกรรมสำหรับแต่ละบล็อก

• ขีดจำกัดการใช้ทรัพยากร

• กำหนดค่าธรรมเนียมการทำธุรกรรม

• ปรับค่าธรรมเนียมการทำธุรกรรมตามเวลา

คลัง

เราระบุทรัพยากรสี่อย่างที่อาจถูกใช้เมื่อประมวลผลธุรกรรม:

1. ความยาว: ขนาดข้อมูลของ tx ในบล็อกลูกโซ่รีเลย์ (เป็นไบต์)

2. เวลา: เวลานำเข้า (i/o และ cpu)

3. หน่วยความจำ: จำนวนหน่วยความจำที่จะเรียกใช้เมื่อจำเป็น

4. สถานะ: เพิ่มการจัดเก็บสถานะ

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

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

1. ความยาว: 5MB,

2. เวลา: 2 วินาที

3. หน่วยความจำ: 10GB

4. สถานะ: การเติบโต 1MB

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

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

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

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

รายละเอียดการใช้ทรัพยากรทั่วไปที่กำหนดไว้สำหรับธุรกรรมที่เป็นปัญหา ตรวจสอบความยาวได้อย่างง่ายดาย สำหรับเวลาและการใช้งานหน่วยความจำ เราได้เตรียมสถานะที่แย่ที่สุดสำหรับรีเลย์เชน (ความต้องการด้านเวลาและหน่วยความจำในการนำเข้าธุรกรรมประเภทนี้ควรเป็นสถานะที่ใหญ่ที่สุด) สำหรับประเภทธุรกรรมที่กำหนด เราใช้สถานะที่ใช้เวลานำเข้านานที่สุดเพื่อสร้างธุรกรรม 10,000 รายการ และวัดค่าเฉลี่ยและส่วนเบี่ยงเบนมาตรฐานของการใช้ทรัพยากรในสภาพแวดล้อม Wasm หากค่าเบี่ยงเบนมาตรฐานมากกว่า 10% ของค่าเฉลี่ย เราจะเพิ่มพื้นที่ตัวอย่างเป็นมากกว่า 10k สุดท้าย ปรับปรุงสถานะโดยการตรวจสอบกับตัวอย่างธุรกรรมที่เลวร้ายที่สุดจำนวนมาก

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

กลับ

ซึ่งจะมีคุณสมบัติดังต่อไปนี้:

สมมติว่าค่าของ v มีค่าน้อย พารามิเตอร์

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

คลัง

ระบบจำเป็นต้องระดมทุนอย่างต่อเนื่อง ซึ่งเราเรียกว่าคลัง เงินเหล่านี้ใช้เพื่อจ่ายเงินให้กับนักพัฒนาซอฟต์แวร์ที่ให้การอัปเดตซอฟต์แวร์ ใช้การเปลี่ยนแปลงใด ๆ ที่ตัดสินโดยการลงประชามติ ปรับค่าพารามิเตอร์ และโดยทั่วไปทำให้ระบบทำงานได้อย่างราบรื่น

กองทุนคงคลังมีการระดมทุนในสองวิธี:

1. โดยการสร้างโทเค็นใหม่ แต่จะทำให้เกิดภาวะเงินเฟ้อ

2. โดยการลบค่าธรรมเนียมการทำธุรกรรมและโทเค็นเครื่องหมายทับที่อาจถูกตั้งค่าให้ไหม้

โดยเฉพาะอย่างยิ่ง วิธีการระดมเงินเหล่านี้เลียนแบบวิธีดั้งเดิมที่รัฐบาลระดมเงิน: โดยการทำเหรียญกษาปณ์และควบคุมอัตราเงินเฟ้อด้วยภาษีและค่าปรับ

เราสามารถระดมทุนได้โดยการสร้างโทเค็นใหม่ แต่เราคิดว่ามันเหมาะสมที่จะเปลี่ยนเส้นทางโทเค็นจากค่าธรรมเนียมการทำธุรกรรมและเฉือนไปที่คลัง ซึ่งมิฉะนั้นอาจถูกทำลาย:

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

2. หลังจากเหตุการณ์ที่ส่งผลให้เกิดการฟันเดิมพันขนาดใหญ่ มักจะเป็นที่พึงปรารถนาที่จะชำระคืนเงินเดิมพันบางส่วนหากมีข้อผิดพลาดในโค้ดหรือมีเหตุสุดวิสัย ดังนั้นจึงเหมาะสมกว่าที่จะใช้ DOT ในคลังมากกว่าเผามันก่อนแล้วจึงสร้างมันออกมา

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

รวบรวม/ย่อง Zhiyao

รองพื้นออริจินอล/WEB3