แนวคิดการปรับปรุงกระบวนการ EIP: การยืมจากกระบวนการ RFC และ W3C

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

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

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

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

สรุปหนึ่งประโยค: ก่อนอื่น ฉันจะแนะนำทั่วไปเกี่ยวกับกระบวนการ EIP และการปรับเปลี่ยนในปี 2019 จากนั้น ฉันจะเสนอกระบวนการ EIP ใหม่ ซึ่งส่วนใหญ่ได้รับแรงบันดาลใจจากกระบวนการ RFC และ W3C

• ตั้งแต่ปี 2559 ฉันมีส่วนร่วมใน EIPs (ข้อเสนอการปรับปรุง Ethereum) ฉันเริ่มต้นจากการเป็นผู้สนับสนุน และต่อมาได้เข้าร่วมใน "กระบวนการ AllCoreDev" และรับงานด้านบรรณาธิการ

• กระบวนการปัจจุบัน

มีสองกระบวนการที่แตกต่างกันในไลบรารี EIP ปัจจุบัน:

ข้อมูลจำเพาะ

• การใช้งานเครือข่ายทั้งหมด (แผนฮาร์ดฟอร์ก)

• EIP-1 ​​และ EIP 233 กำหนดส่วนของกระบวนการทั้งสอง ต่อมา EIP-2378 ได้ขยายตัวบนพื้นฐานนี้

• ในปี 2019 มีการเสนอการเปลี่ยนแปลงหลายรายการ โดย 4 รายการเกี่ยวข้องกับสถานะของข้อเสนอ:

• แนะนำสถานะ "รีวิว"

เปลี่ยนชื่อ "ยอมรับ" เป็น "พร้อม"

แนะนำสถานะ "ละทิ้ง"

ลบสถานะ "เลื่อน"

แรงจูงใจในการแนะนำการเปลี่ยนแปลงสองรายการแรกนั้นคล้ายกัน แต่แตกต่างกันเล็กน้อย สถานะ "ตรวจสอบ" เป็นขั้นตอนใหม่ที่ข้อเสนอจะไม่ถูกนำไปใช้อย่างเร่งด่วน แม้ว่าจะมีข้อเสนอที่ชัดเจนที่เปิดให้พิจารณาในวงกว้าง สถานะ "พร้อม" เป็นเพียงการเปลี่ยนแปลงที่เพิ่มขึ้นเล็กน้อย และน้ำเสียงจะนุ่มนวลกว่า "ยอมรับ" แต่กระบวนการฮาร์ดฟอร์กใน EIP-1 ​​ยังคงอยู่

สถานะ "ละทิ้ง" ถูกนำมาใช้เพื่อล้างแบบร่างที่ถูกละทิ้งจำนวนมาก เห็นได้ชัดว่า สถานะ "ถอนออก" ที่ไม่ได้ใช้ก่อนหน้านี้ได้ถูกลบออกไปแล้ว

เนื่องจากการเปลี่ยนแปลงใน EIP-233 และ EIP-2378 สถานะ "รอการตัดบัญชี" จึงล้าสมัยและถูกลบออก

นอกจากนี้ยังมีข้อเสนอให้ลบสถานะ hard fork อื่นๆ เช่น "Accepted" และ "Rejected"

โปรดทราบว่าฉันจะไม่อธิบายรายละเอียดว่าแต่ละสถานะหมายถึงอะไรในแผนภาพด้านล่าง โปรดอ่าน EIP-1 ​​สำหรับเคสแต่ละมุม อย่างไรก็ตาม 'กระบวนการที่เสนอ' ด้านล่างให้คำอธิบายที่สมเหตุสมผล "

ในเดือนมิถุนายน 2019 เราได้หารือเชิงลึกเกี่ยวกับความซับซ้อนของกระบวนการ EIP หากพิจารณาแต่ละสถานะ โฟลว์ EIP ทั้งหมด (ก่อนสถานะ "เลื่อนออกไป" จะถูกลบออก) จะแสดงในไดอะแกรมต่อไปนี้:

ในเวลานั้น ฉันคิดว่า EIP สามารถเปลี่ยนจากสถานะ "การโทรครั้งสุดท้าย (ครั้งสุดท้ายสำหรับความคิดเห็น)" เป็นสถานะ "ละทิ้ง" แม้ว่าจะไม่ได้เขียนไว้ในเอกสารก็ตาม

สิ่งที่ฉันไม่ได้พูดถึงคือมี EIP สองรายการที่มีกระบวนการต่างกัน และการใช้ชุดค่าผสมด้านบนทั้งหมดไม่ถูกต้อง

การไหลของ EIP "แกนกลาง" เป็นดังนี้:

ควรสังเกตที่นี่ว่า EIP "หลัก" ไม่ได้แนะนำสถานะ "การโทรครั้งสุดท้าย" จนกระทั่งเมื่อไม่นานมานี้

กระบวนการสำหรับ EIP "ที่ไม่ใช่คอร์" มีดังต่อไปนี้:

ในเดือนพฤษภาคม 2020 ฉันเสนอกระบวนการที่ง่ายกว่านี้:

เราได้พูดถึงประเด็นนี้แล้ว แต่เช่นเดียวกับข้อเสนอมากมายที่กำลังเข้าสู่กระบวนการ EIP ข้อเสนอนี้ไม่ได้ก้าวไปข้างหน้า

ฮาร์ดส้อม

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

ในการประชุมทางโทรศัพท์ มีคำแนะนำให้ใช้คำว่า "Living" แทนคำว่า "Active" แบบแรกอาจไม่ใช่ตัวเลือกที่ดีที่สุด แต่ฟังดูดีกว่าแบบหลัง

ฮาร์ดส้อม

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

ตามข่าวใหม่จากการประชุมนักพัฒนาแบบ all-core ขณะนี้ดูเหมือนจะเป็นที่เก็บข้อมูลจำเพาะ ETH 1.0 สำหรับการติดตามและจัดการข้อเสนอ และทดสอบบนเครือข่ายชั่วคราวที่เรียกว่า "YOLO"

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

อย่างไรก็ตาม ผู้คนได้ก้าวไปอีกขั้นจากแนวคิดดั้งเดิมของ EIP-233 และกฎกลายเป็นการสร้างเอกสารเมตาโดยเร็วที่สุดเพื่อชี้แจงชื่อของการฮาร์ดฟอร์ก เนื่องจากไคลเอนต์ต่างใช้ชื่อต่างกัน แต่หลังจากตกลงกลไกการตั้งชื่อแล้ว ปัญหานี้ก็ไม่เป็นปัญหาอีกต่อไป

ในที่สุด แนวคิดของ EIP-233 ก็ขยายออกไปอีกครั้ง โดยขยายกระบวนการติดตามฮาร์ดฟอร์กในกระบวนการวางแผนและการประสานงาน โชคดีที่ในอนาคตสิ่งนี้จะได้รับการจัดการโดยข้อกำหนดเฉพาะของ ETH 1.0

หลังจากเกิดการ hard fork ข้อมูลทั้งหมดจะถูกบันทึกไว้ใน "เมตาของ hard fork" metas ของฮาร์ดฟอร์ดได้พิสูจน์แล้วว่าเป็นทรัพยากรที่มีประโยชน์มาก

กระบวนการที่ฉันแนะนำ

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

ในที่นี้ ฉันขอยืมคำศัพท์ส่วนตัวที่ฉันชื่นชอบจากกระบวนการ W3C อย่างไรก็ตาม มีตัวเลือกอื่นๆ ที่ระบุในรูปด้านบน ทั้งข้อกำหนดที่มีอยู่หรือข้อกำหนดที่เสนอ ฉันชอบคำว่า "ผู้สมัคร" เป็นการส่วนตัว

ความคิด

ก่อนที่จะส่งข้อเสนอใด ๆ ควรมีขั้นตอนการพิจารณาก่อนที่จะส่งคำขอดึง (คำขอดึง) ที่สร้างร่าง เราสามารถพูดคุยและวิจารณ์แนวคิดเกี่ยวกับ Ethereum Magicians, ethresear.ch และช่องบน Gitter หรือ Discord

ร่าง

สมมติว่าแนวคิดหนึ่งดึงดูดความสนใจ เราควรสร้างแบบร่างตามเทมเพลต EIP ตราบใดที่แบบร่างนี้ตรงตามข้อกำหนดทางไวยากรณ์พื้นฐาน เราควรรวมเข้าด้วยกัน

คำถาม: ความคิดเห็นแตกต่างกันไปตามจำนวนบรรณาธิการที่มีอำนาจในการทบทวนข้อเสนอ และไม่มีคำตอบที่ชัดเจน หากเรามีกระบวนการที่ดีในการลบ EIP ที่ไม่สำเร็จ การรวมแบบร่างก่อนหน้านี้เป็นสิ่งที่ถูกต้องอย่างแน่นอน

ในขั้นตอนนี้ คาดว่าจะมีการอภิปรายร่างร่างโดยผู้เข้าร่วมกลุ่มเล็กๆ ที่สนใจ

ไม่มีการจำกัดเวลาสำหรับสถานะ "ฉบับร่าง" แต่ขอแนะนำไม่ให้เกินกรอบเวลาที่เหมาะสม (ไม่กี่เดือน)

ผู้สมัคร (ผู้สมัคร)/ทบทวน (ทบทวน)

ควรเข้าสู่ขั้นตอนนี้เมื่อแบบร่างมีความเสถียรเพียงพอที่คาดว่าจะไม่มีการแก้ไขที่สำคัญเพิ่มเติมอีก

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

ขั้นตอนนี้ควรใช้เวลาอย่างน้อย 45 วันเพื่อให้สามารถรวบรวมความคิดเห็นได้

เสนอ (เสนอ) / Last Call (โทรครั้งสุดท้ายสำหรับความคิดเห็น)

ควรเข้าสู่ขั้นตอนนี้เมื่อผู้เข้าร่วมรู้สึกว่าข้อมูลจำเพาะมีเสถียรภาพเพียงพอที่จะไม่มีการเปลี่ยนแปลงเพิ่มเติม

ในขั้นตอนนี้ ข้อกำหนดจะถูกส่งไปยังผู้เข้าร่วมเพิ่มเติมเพื่อแสดงความคิดเห็น หลังจากนั้นจะถือว่าข้อกำหนดเสร็จสิ้นและไม่สามารถเปลี่ยนแปลงได้ [ยกเว้น "errata (kan)" ดูรายละเอียดด้านล่าง]

ขั้นตอนนี้ควรใช้เวลาอย่างน้อย 14 วัน

หากจำเป็นต้องมีการปรับเปลี่ยนเล็กน้อย ก็สามารถทำได้โดยไม่ต้องเปลี่ยนสถานะปัจจุบัน มิฉะนั้น จะต้องถอยกลับไปสู่สถานะ "ผู้สมัคร"

ข้อกำหนดพิเศษ: ต้องรวมฟิลด์วันที่สิ้นสุดการตรวจทานไว้ในส่วนหน้า

สุดท้าย

หากผ่านข้อกำหนดในสถานะ "เสนอ" สำเร็จ ก็จะถือว่าเสร็จสิ้น

• ถอนออก

• ยกเว้นสถานะ "สุดท้าย" และ "ชีวิต" สถานะอื่นๆ ทั้งหมดอาจกลายเป็นสถานะนี้

ข้อกำหนดพิเศษ: สถานการณ์ต่อไปนี้อาจนำไปสู่สถานะ "ถอนออก" แต่ต้องมีฟิลด์เหตุผล:

ผู้เขียนถอนตัว: ผู้เขียนตัดสินใจถอนตัวในทุกขั้นตอน

ถอนออกเนื่องจากไม่มีการใช้งาน: ผู้เขียนไม่มีกิจกรรมตามระยะเวลาที่กำหนด (180 วัน)

อยู่อาศัย/ใช้งาน

EIP-1 ​​เหล่านั้นเป็นรีจิสตรีและ EIP พิเศษอื่น ๆ จะถูกทำเครื่องหมายด้วยสถานะนี้ เนื่องจากจะไม่มีการสิ้นสุด

เอกสารการจดทะเบียนใหม่ใดๆ จะต้องผ่านกระบวนการ EIP เต็มรูปแบบก่อนที่จะมีสถานะ "มีชีวิต"

เก็บถาวร

• แม้ว่านี่จะไม่ใช่สถานะ แต่ด้วยวิธีนี้ EIP ที่ถูกเพิกถอนเป็นเวลานานสามารถลบออกได้เพื่อหลีกเลี่ยงการเติมไลบรารี EIP คลิกที่นี่เพื่อดูรายละเอียด

• ล้าสมัย

นี่ไม่ใช่สถานะ แต่เป็นกระบวนการเลิกใช้ที่ยืมมาจาก RFC กระบวนการนี้แนะนำสองฟิลด์:

ล้าสมัยโดย: มีหมายเลข EIP ที่ล้าสมัย EIP ปัจจุบัน

ล้าสมัย: ประกอบด้วยชุดของหมายเลข EIP ที่ล้าสมัยโดย EIP ปัจจุบัน

EIP ปัจจุบันสามารถใช้ฟิลด์ที่ล้าสมัยได้เมื่ออยู่ในสถานะ Final หรือ Withdrawn เท่านั้น

EIP ปัจจุบันสามารถมีฟิลด์ล้าสมัยได้หากฟิลด์ "เลิกใช้แล้ว" ของ EIP ที่อ้างอิงชี้ไปที่ EIP ปัจจุบัน

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

Remark

Errata (เออร์ราต้า)

• ข้อผิดพลาดเล็กน้อยในการพิมพ์อาจได้รับการแก้ไขโดยบรรณาธิการตามแบบแผน

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

• resolution

ฟิลด์ frontmatter ต่อไปนี้ถูกลบออกเนื่องจากไม่ได้ระบุและ/หรือใช้:

แทนที่ (แทนที่ด้วยกระบวนการกำจัด)

• แทนที่ด้วย (แทนที่ด้วยกระบวนการกำจัด)

• Rejected

• Accepted

• สถานะต่อไปนี้จะถูกลบออก:

เครื่องมือ

ละทิ้ง (เปลี่ยนชื่อเป็น "ถอน")

แทนที่ (แทนที่ด้วยกระบวนการกำจัด)

เครื่องมือ

อย่างไรก็ตาม ความท้าทายที่ใหญ่ที่สุดที่ EIP ต้องเผชิญคือความต้องการกำลังคน