ข้อเสนอการปรับปรุง Ethereum และข้อเสนอการปรับปรุงกระบวนการอัปเกรด

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

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

สรุป

โพสต์นี้เป็นบทสนทนาคร่าวๆ ของการสนทนาระหว่าง Danno Ferrin และฉันมีที่งาน DevconV (งาน Ethereum Developers Conference ครั้งที่ 6) บทความนี้กล่าวถึงคำแนะนำในการปรับปรุงกระบวนการ EIP ที่ชุมชนเสนอในปีที่ผ่านมา และรวมไว้ในกรอบการทำงานที่เป็นหนึ่งเดียวเพื่อแนะนำเราเกี่ยวกับวิธีอัปเกรด Ethereum ให้ราบรื่นยิ่งขึ้น เราเรียกมันว่า "โมเดลสถานีรถไฟ"

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

• สรุป

• จากข้อเสนอหลายข้อจากชุมชนในปีที่ผ่านมา เราเสนอวิธีการใหม่สำหรับการประสานงานการอัปเกรดบนเครือข่าย Ethereum โดยเฉพาะอย่างยิ่ง เราเชื่อว่า:

• การอัปเกรดควรเกิดขึ้นปีละสองครั้งเพื่อให้ชุมชนคาดการณ์ได้ชัดเจน

การอัปเกรดควรมีเฉพาะ Ethereum Improvement Proposals (EIPs) ที่พร้อมเผยแพร่ และการปรับปรุงใด ๆ ที่ยังอยู่ภายใต้การอภิปรายควรใส่ในการอัปเกรดครั้งต่อไปและไม่ทำให้การอัปเกรดปัจจุบันล่าช้า

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

ข้อเสนอการปรับปรุง Ethereum และคณะทำงานควรมีผู้สนับสนุนหรือตัวแทนเพื่อติดต่อกับชุมชนและตอบคำถามของชุมชนเกี่ยวกับ EIP ที่เกี่ยวข้อง

เรามาคุยกันสั้น ๆ เกี่ยวกับประวัติการอัพเกรดของ Ethereum การอัพเกรดเครือข่ายสองสามครั้งแรก ได้แก่ Frontiers, Homeland, Byzantium และ Constantinople เป็นเหมือนการพักร้อนของครอบครัวในทศวรรษ 1950 ที่พ่อกับแม่จะแกะรถและเราจะกระโดดขึ้นเบาะหลังและอาจนำของเล่นชิ้นโปรดของเราไปด้วย จะพาเราไปถึงที่หมายโดยสวัสดิภาพ

นี่เป็นการเปรียบเทียบง่ายๆ สำหรับการอัปเกรดในอดีต แต่สำหรับการอัปเกรดเหล่านี้ นักพัฒนาหลักได้เขียนข้อเสนอการปรับปรุง Ethereum ส่วนใหญ่ และชุมชน Ethereum มีขนาดเล็กพอที่จะสื่อสารกับชุมชนอย่างเป็นระบบและวางแผนได้ ทำให้ ส้อมและการอัพเกรดเป็นไปอย่างราบรื่น

…. แต่ก็มีบางครั้งที่พวกเขายุ่งเกินไป! น้อยครั้งที่เราต้องรีบผจญเพลิง ในโอกาสนั้น โดยพื้นฐานแล้วเราทุกคนล้วนเป็นทหาร ไม่ว่าจะเป็นการโจมตีทางไซเบอร์ระหว่าง Devcon 2 ในเซี่ยงไฮ้ การ fork ของ Ethereum ที่เกิดจาก DAO หรือจุดอ่อนที่ค้นพบในนาทีสุดท้ายก่อนการอัปเกรดคอนสแตนติโนเปิล ชุมชนมักจะรวมตัวกันเพื่อแก้ไขจุดบกพร่อง แก้ปัญหา และให้ผู้ใช้อัปเกรดโหนดได้ทันเวลา .

คำอธิบายภาพ

-น้ำตกที่เป็นสีของ ethereum-

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

อย่างไรก็ตาม โหนดเวลาที่วางแผนไว้เหล่านี้เสร็จตรงเวลากี่โหนด มีเพียงหนึ่งเดียวและนั่นคือจุดเริ่มต้น

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

คำอธิบายภาพ

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

คำอธิบายภาพ

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

Ethereum 1.X จะพยายามเปลี่ยนกระบวนการพัฒนา EIP

ระหว่างการอัพเกรดอิสตันบูล คนแรกที่พยายามแก้ปัญหากระบวนการพัฒนาคือ Alexey Akhunov เขาเขียนบล็อกโพสต์ (หมายเหตุบรรณาธิการ: ดูไฮเปอร์ลิงก์ที่ส่วนท้ายของบทความสำหรับการแปลภาษาจีน) อธิบายถึงวิธีที่เราสามารถใช้ ReTestEth เพื่อเพิ่มจำนวนสมาชิกที่มีส่วนร่วมในการปรับปรุงโปรโตคอล Ethereum โดยการจัดตั้งคณะทำงาน ในขณะที่ลดจำนวนลง ภาระของนักพัฒนาหลักที่มีอยู่ ภาระ ในกระบวนการปรับปรุง "ก่อน 1.x" ข้อเสนอการปรับปรุง Ethereum ที่ส่งมาจะถูกนำไปใช้โดยนักพัฒนาลูกค้าของ Geth, Parity และ Aleth เป็นหลัก ซึ่งในกรณีนี้ ข้อเสนอการปรับปรุง Ethereum จะได้รับการปรับปรุงร่วมกันโดยทีมเหล่านี้ เมื่อลูกค้าตกลงเกี่ยวกับข้อกำหนดขั้นสุดท้ายของข้อเสนอการปรับปรุง Ethereum แล้ว ก็จะสามารถสร้างการทดสอบอ้างอิงได้ Aleth เป็นไคลเอ็นต์รายเดียวที่สามารถสร้างการทดสอบได้ ดังนั้นเพื่อสร้างการทดสอบเหล่านี้ ข้อเสนอการปรับปรุง Ethereum ทั้งหมดจำเป็นต้องดำเนินการใน Aleth จากนั้นทีมทดสอบของ EF จะทำการทดสอบเหล่านี้และเขียนการทดสอบความสอดคล้องที่ลูกค้าทุกคนจะดำเนินการ

- รูปภาพในสไลด์โชว์นำมาจากโพสต์ต้นฉบับของ Alexey-

มีปัญหาคอขวดหลายประการในกระบวนการนี้: ทีมดำเนินการไคลเอนต์หลัก การทดสอบอ้างอิงที่สร้าง Aleth และการทดสอบความสอดคล้องที่เขียนโดยทีมทดสอบของ EF เพื่อปรับปรุงประสิทธิภาพการทำงาน Alexey ได้เสนอแนวคิดในการตั้งคณะทำงาน คณะทำงานเหล่านี้จะประกอบด้วยบุคคลกลุ่มย่อยที่มีความปรารถนาร่วมกันในการปรับปรุง Ethereum พวกเขาสามารถเริ่มต้นจากช่วงเริ่มต้นของข้อเสนอการปรับปรุง Ethereum และช่วยปรับแต่งเพื่อให้ใกล้เคียงกับรุ่นสุดท้ายมากขึ้นหรือน้อยลง ด้วยวิธีนี้ นักพัฒนาไคลเอนต์จะเห็นข้อเสนอการปรับปรุง Ethereum ที่บรรลุนิติภาวะแล้ว อย่างน้อยอาจเป็นการใช้งานครั้งแรก และคำถามเปิดที่เกี่ยวข้องส่วนใหญ่ได้รับคำตอบแล้ว

นอกจากนี้ retesth ซึ่งเป็นเครื่องมือทดสอบใหม่ที่พัฒนาโดยทีมทดสอบของ EF จะช่วยให้คณะทำงานสร้างการทดสอบอ้างอิง EIP ที่จำเป็นสำหรับไคลเอนต์ใดๆ (ปัจจุบันคือ Geth, Aleth และ Hyperledger Besu) ดังนั้น กรอบการทำงานของคณะทำงานนี้จะไม่เพียงกระจายอำนาจของกระบวนการปรับแต่งข้อเสนอการปรับปรุง Ethereum เท่านั้น แต่ยังช่วยลดปัญหาคอขวดและแรงกดดันในการทดสอบอีกด้วย

ผู้สนับสนุน eEIP

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

คำอธิบายภาพ

-ขอบคุณ MP และ Boris สำหรับความช่วยเหลือในการจัดเวิร์กช็อปเพื่อหารือเกี่ยวกับประเด็นเหล่านี้-

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

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

ส้อม EIP ศูนย์กลาง

อีกแนวคิดหนึ่งที่เพิ่งเสนอโดย Martin Holst Swende จากทีม EF คือการปรับแต่งกระบวนการอัปเกรดเครือข่าย Ethereum ให้เน้น EIP เป็นศูนย์กลางมากขึ้น แทนที่จะมุ่งเน้นไปที่การอัปเกรดและพยายามตรวจสอบให้แน่ใจว่าข้อเสนอการปรับปรุง Ethereum ทั้งหมดอยู่ในขั้นตอนล็อคในแต่ละขั้นตอนของการอัปเกรด จะเป็นการดีกว่าหากมุ่งเน้นไปที่การทำให้แต่ละ EIP สมบูรณ์และวางแผนการอัปเกรดเฉพาะ EIP ที่สมบูรณ์และเผยแพร่ได้

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

ขั้นตอนที่ 1: รับการยืนยันจาก ACD

สมมติว่าข้อเสนอการปรับปรุง Ethereum มีอยู่ (ขั้นตอนที่ 0) ALCORIEDEV (ฟอรัม) จะตัดสินใจในเบื้องต้นว่าข้อเสนอการปรับปรุง Ethereum นั้น "ได้รับการยอมรับในเบื้องต้น" หรือไม่ "การยอมรับเบื้องต้น" (หรือ "เชิงบวก") หมายความว่าลูกค้ารายใหญ่และผู้มีส่วนได้ส่วนเสียในระบบนิเวศมีทัศนคติเชิงบวกต่อข้อเสนอการปรับปรุง Ethereum ยินดีที่จะยอมรับ (เขียนอย่างดี) PRs เพื่อรวม EIP เข้ากับฐานรหัสและเริ่มการทดสอบ .. . แต่ขั้นตอนนี้จะไม่ระบุความสูงของบล็อกจริงของการเปิดใช้งาน

สถานะ "การยอมรับเบื้องต้น" นี้ยังเป็นกลไกการส่งสัญญาณที่มีประโยชน์สำหรับการอัปเกรดโปรโตคอลการจัดหาเงินทุนขององค์กร เช่น EF, ConsenSys หรือแม้แต่ MolochDAO เงินทุนสามารถแบ่งออกเป็นหลายช่วง (เช่น ก่อนและหลัง "การยอมรับเบื้องต้น") เพื่อให้แน่ใจว่าเงินทุนส่วนใหญ่ถูกใช้ไปกับการริเริ่มที่อำนวยความสะดวกในการเปิดตัว mainnet

ขั้นตอนที่ 2: ดำเนินการ

เมื่อ ACD ได้กำหนดทิศทางที่ชัดเจนแล้ว นักพัฒนาและผู้เขียนข้อเสนอการปรับปรุง Ethereum อื่นๆ สามารถทำงานเพื่อดำเนินการและเผยแพร่การอัปเดตสำหรับลูกค้าได้

เหตุการณ์สำคัญนี้จะเสร็จสมบูรณ์หากมีการรวมฟังก์ชันการใช้งานเข้ากับไคลเอนต์หลัก

ขั้นตอนที่ 3: กรณีทดสอบ

เนื่องจากคุณลักษณะนี้สามารถ "เปิดใช้งาน" ในไคลเอ็นต์ได้แล้ว จึงสามารถสร้างการทดสอบข้ามไคลเอ็นต์สำหรับคุณลักษณะนี้ได้ กรณีทดสอบควรมีการทดสอบแบบ Happy-Path และการทดสอบแบบแปลก/ขอบกรณี ขั้นตอนนี้ไม่ควรมอบให้เฉพาะ ผู้ที่เข้าใจเชิงลึกและเข้าใจ EVM (Ethereum Virtual Machine) จะดำเนินการร่วมกันเพื่อลดความเป็นไปได้ของข้อผิดพลาด

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

ขั้นตอนที่ 4: การยอมรับขั้นสุดท้ายของ ACD

“ดังนั้น เรามาเปิดใช้งานข้อเสนอการปรับปรุง Ethereum นี้ (ที่ความสูงบล็อก X) ใน testnet หนึ่งเดือนต่อมา และเปิดใช้งานข้อเสนอการปรับปรุง Ethereum นี้บน mainnet (ที่ความสูงบล็อก Y) ในอีกสองเดือนต่อมา” ลูกค้าทั้งหมดจะรวมการอัปเกรดไว้ในรุ่นถัดไป และเป็นไปได้จริงที่จะเลื่อนข้อเสนอการปรับปรุง Ethereum ผ่านแฟล็กบรรทัดคำสั่งเป็นเวลาหนึ่งสัปดาห์นับจากนี้

หากข้อเสนอการปรับปรุง Ethereum หลายรายการไปถึงขั้นตอนที่ 4 ในเวลาเดียวกัน ACD สามารถตัดสินใจที่จะเปิดตัวข้อเสนอการปรับปรุง Ethereum สองหรือสามรายการพร้อมกัน เว้นแต่จะมีข้อกังวลว่าข้อเสนอการปรับปรุง Ethereum อาจมีการอ้างอิง/ข้อต่อภายใน (ซึ่งอาจนำไปสู่ รบกวนการทดสอบโดยไม่จำเป็น)

คำอธิบายภาพ

- ขอบคุณ James Hancock สำหรับการวาดภาพที่ชัดเจน! -

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

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

• ข้อเสนอการปรับปรุง Ethereum ปี 1872

• ข้อเสนออีกประการหนึ่งที่จะทำให้กระบวนการอัปเกรดเครือข่าย Ethereum เป็นไปอย่างราบรื่นคือ Proposition 1872 ซึ่งเสนอโดย Danno Ferrin เนื่องจากบริษัทจำนวนมากขึ้นใช้ Ethereum เป็นส่วนสำคัญของโครงสร้างพื้นฐาน เราควรพยายามทำให้การอัปเกรดเครือข่ายสามารถคาดการณ์ได้มากขึ้น

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

• กำหนดให้การอัปเกรด mainnet เป็นค่าเริ่มต้นในวันพุธที่สามของเดือน ควรจะเป็นในเดือนมกราคม เมษายน กรกฎาคม หรือตุลาคม เพื่อหลีกเลี่ยงวันหยุดที่สำคัญส่วนใหญ่ของสหรัฐอเมริกาและยุโรป

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

เมื่อไรก็ตามที่เกิดปัญหาให้แก้ไขทันที

EIP นี้จะไม่จำกัดความสามารถของเราในการจัดการกับสถานการณ์ที่คาดไม่ถึงแต่เน้นเฉพาะระยะเวลาเริ่มต้น เช่น การอัปเกรดแบบคงที่ทุกๆ 6 เดือน เพื่อลดความกังวลของตลาดเกี่ยวกับความไม่แน่นอนของการอัปเกรด กระบวนการ.

นอกจากนี้ยังให้ "จุดกึ่งกลาง" ระหว่างแนวทางปัจจุบันของเรากับแนวทาง "หนึ่งข้อเสนอการปรับปรุง Ethereum หนึ่งการอัปเกรด" (เช่น แนวทาง EIP-centric fork)

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

โมเดลสถานีรถไฟฟ้า

เมื่อรวมส่วนต่างๆ ของคำแนะนำข้างต้น เราได้มาถึงกระบวนการที่ใกล้เคียงกับวิธีการทำงานของสถานีรถไฟมากกว่ากระบวนการ "ใกล้เคียงกับวิธีการทำงานของสนามบิน" ในปัจจุบันของเรา

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

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

โดยเฉพาะอย่างยิ่ง โมเดลสถานีรถไฟ ส่วนใหญ่มีสี่ส่วน

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

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

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