แหล่งที่มาดั้งเดิม: การอัปเดต AllCoreDevs

แหล่งที่มาดั้งเดิม: การอัปเดต AllCoreDevs

ผู้เขียน: ทิม เบโค

การรวบรวมต้นฉบับ: Ethereum.cn

ยินดีต้อนรับสู่การอัปเดต AllCoreDevs (Ethereum Core Developers Conference) ใหม่ ซึ่งเป็นการอัปเดตล่าสุดสำหรับปี 2022

แม้ว่าการอัปเดตเหล่านี้จะเริ่มต้นเป็นซีรีส์รายเดือน แต่จังหวะก็ค่อย ๆ เปลี่ยนไปเป็นการอัปเดตรายไตรมาส ผู้อ่านสามารถคิดว่าการอัปเดตเหล่านี้เป็นบทสรุปของเหตุการณ์สำคัญรอบ ๆ AllCoreDevs หากคุณต้องการรายละเอียดเพิ่มเติม ฉันขอแนะนำให้อ่านข้อความถอดเสียงของ Christine Kim, บันทึกการประชุมเลเยอร์ฉันทามติของ Ben Edginton และทวีตแบบยาว ACD ของฉัน ซึ่งอัปเดตบ่อยกว่า

สรุป

สรุป

เนื้อหาของการอัปเกรด Shanghai/Capella ได้รับการสรุปแล้ว: การถอนเงิน EOF และการแก้ไขเล็กน้อย...หากไม่ชะลอการถอน

Blob Space กำลังจะมา: EIP-4844 จะเป็นศูนย์กลางของการอัปเกรดครั้งต่อไปของ Ethereum และพิธีอัญเชิญจะเริ่มขึ้นในไม่ช้า

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

ชื่อระดับแรก

เซี่ยงไฮ้/คาเปลลาอัพเกรด

ที่งาน AllCoreDevs ล่าสุด ทีมลูกค้าได้รับฉันทามติเกี่ยวกับขอบเขตขั้นสุดท้ายของการอัปเกรด Shanghai/Capella แม้ว่าชื่อของการอัปเกรดอาจเป็นที่ถกเถียงกัน แต่ทีมก็ชัดเจนในขอบเขตของมัน หน้าที่หลักของการอัพเกรดคือการแนะนำการถอน beacon chain สำหรับนักเดิมพัน การนำคุณลักษณะนี้ออกให้เร็วที่สุดเป็นสิ่งที่ทีมลูกค้าไม่ต้องการประนีประนอม ดังนั้นคุณลักษณะอื่นๆ ในการอัปเกรดจำเป็นต้องพร้อมพร้อมกัน มิฉะนั้นอาจถูกทิ้ง

Shanghai Executive Specification แสดงรายการ EIP ที่รวมทั้งหมด:

EIP-3540: รูปแบบวัตถุ EVM (EOF) v1

EIP-3651: ลดค่าใช้จ่ายในการเข้าถึงที่อยู่ COINBASE

EIP-3670: EOF - การตรวจสอบรหัส

EIP-3855: ใหม่ opcode PUSH 0

EIP-3860: จำกัดขนาด initcode และแนะนำการวัดปริมาณก๊าซ

EIP-4200: EOF - การกระโดดสัมพัทธ์คงที่

EIP-4750: EOF - ฟังก์ชันนำเข้า

EIP-4895: Beacon Chain ทำการถอนออกโดยเป็นการทำงานของระบบ

EIP-5450: EOF - การตรวจสอบความถูกต้องของสแต็ก

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

การปรับปรุงเล็กน้อย

EIP-3651: อุ่น COINBASE (ลดค่าใช้จ่ายในการเข้าถึงที่อยู่ COINBASE)

EIP นี้แก้ไขการกำกับดูแลใน EIP-2929 ซึ่งการปรับเปลี่ยนต้นทุนก๊าซสำหรับการเข้าถึงฟิลด์ข้อมูลบางอย่างขึ้นอยู่กับว่าข้อมูลนั้นอยู่ในหน่วยความจำไคลเอนต์ (WARM) หรือจำเป็นต้องดึงข้อมูลจากดิสก์ (COLD)

EIP-2929 ตั้งค่าข้อมูลสองส่วนในหน่วยความจำไคลเอนต์เป็น WARM เมื่อเริ่มต้นการทำธุรกรรมแต่ละครั้ง: ที่อยู่ผู้ส่งและที่อยู่ผู้รับ EIP-3651 เพิ่มที่อยู่ที่สามลงในรายการนี้ ที่อยู่ COINBASE (เช่น ผู้รับค่าธรรมเนียม) เนื่องจากเป็นที่อยู่ที่ไคลเอนต์มีอยู่ในหน่วยความจำเมื่อประมวลผลธุรกรรมบล็อก

EIP-3855: คำสั่ง PUSH 0 (เพิ่ม opcode `PUSH 0)

ตามชื่อที่แนะนำ EIP-3855 แนะนำ opcode ที่ผลักค่า 0 ไปยังสแต็ก การกด 0 มักจะใช้เพื่อเติมค่าใน EVM opcode นี้จะให้วิธีที่มีประสิทธิภาพและถูกกว่าในการทำเช่นนี้

EIP-3860: Limit and meter initcode (ตั้งค่าจำกัดขนาดของ initcode และแนะนำการวัดก๊าซ)

EIP นี้เพิ่มขีดจำกัดขนาดของ initcode และแนะนำการวัดปริมาณก๊าซตามความยาว ขนาดสูงสุดจะเพิ่มค่าคงที่ให้กับ EVM ซึ่งทำให้เข้าใจและเสนอการเปลี่ยนแปลงได้ง่ายขึ้น

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

รูปแบบวัตถุ

EIPs ส่วนใหญ่ที่รวมอยู่ในการอัปเกรด Shanghai เป็นส่วนหนึ่งของคุณสมบัติเดียว: EVM Object Format (EOF) งานนี้แบ่งออกเป็น 5 EIP ที่แตกต่างกันเพื่อช่วยให้นักพัฒนาไคลเอ็นต์เข้าใจการแก้ไขแต่ละรายการ แต่เพื่อให้ภาพรวมในระดับที่สูงขึ้น นักพัฒนาจึงเผยแพร่ข้อกำหนดแบบรวม EIPs ของ EOF ทั้งห้าคือ:

EIP-3540: รูปแบบวัตถุ EVM เวอร์ชัน 1

EIP-3670: EOF - การตรวจสอบรหัส

EIP-4200: EOF - การกระโดดสัมพัทธ์คงที่

EIP-4750: EOF - ฟังก์ชันนำเข้า

EIP-5450: EOF - การตรวจสอบความถูกต้องของสแต็ก

เป็นที่น่าสังเกตว่าขั้นตอนแรกของ EOF เกิดขึ้นในลอนดอนได้อัปเกรด EIP-3541 ซึ่งสงวนคำนำหน้า 0xEF 00 สำหรับสัญญา EOF ช่วง EOF สำหรับการอัปเกรด Shanghai ก็เปลี่ยนไปเช่นกันในช่วงไม่กี่เดือนที่ผ่านมา

ในเดือนกุมภาพันธ์ ทีมลูกค้าตกลงที่จะพิจารณาการอัปเกรดในเซี่ยงไฮ้เพื่อรวม EOF EIP ที่เล็กที่สุดสองรายการ ได้แก่ EIP 3540 และ 3670 สิ่งเหล่านี้ทั้งหมดจะทำหน้าที่เป็นหน่วยการสร้าง แต่หากไม่มีการเปิดตัว EIP 4200, 4750 และ 5450 ก็จะไม่สามารถใช้งานได้อย่างสมบูรณ์ แม้ว่าจะสามารถขยาย EOF ได้ แต่ความเข้ากันไม่ได้แบบย้อนกลับอาจต้องใช้เวอร์ชันใหม่ เนื่องจากสัญญาก่อน EOF หรือกับ EOF เวอร์ชันเฉพาะจะต้องดำเนินการได้เสมอ EOF เวอร์ชันใหม่แต่ละเวอร์ชันหมายความว่านักพัฒนาไคลเอนต์ต้องรักษากฎการดำเนินการ EVM ชุดใหม่ควบคู่ไปกับกฎเก่า

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

ด้วยเหตุนี้ ในช่วงไม่กี่เดือนที่ผ่านมา ทีมลูกค้าจึงเริ่มชื่นชอบ "EOF ขนาดใหญ่"วิธีการ ด้วยวิธีนี้ แม้ว่าพวกเขาจะต้องใช้ชุดการแก้ไขที่ใหญ่ขึ้น แต่เวอร์ชัน EOF จะมีอายุการใช้งานยาวนานกว่า และลด "EVM คู่ขนาน" ที่ต้องบำรุงรักษา"ตัวเลข. ดังนั้น นักพัฒนาจึงพิจารณา "EOF ขนาดใหญ่" และรวมเข้ากับการอัปเกรดเซี่ยงไฮ้ในที่สุด

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

EIP-3540: รูปแบบวัตถุ EVM (EOF) v1 (รูปแบบวัตถุ EVM เวอร์ชัน 1)

EIP-3540: รูปแบบวัตถุ EVM (EOF) v1 (รูปแบบวัตถุ EVM เวอร์ชัน 1)

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

EIP-3670: EOF - การตรวจสอบรหัส (EOF - การตรวจสอบรหัส)

EIP-3670 สร้างบนคอนเทนเนอร์ที่เปิดตัวในปี 3540 ช่วยให้มั่นใจได้ว่ารหัสในสัญญา EOF นั้นถูกต้องหรือป้องกันไม่ให้ใช้งาน

ซึ่งหมายความว่าไม่สามารถปรับใช้ opcodes ที่ไม่ได้กำหนดในสัญญา EOF ซึ่งมีประโยชน์เพิ่มเติมในการลดจำนวนเวอร์ชัน EOF ที่ต้องเพิ่ม หากมีการเพิ่ม opcode ใหม่ กฎการตรวจสอบสามารถเปลี่ยนแปลงได้ง่ายๆ เพื่อเปิดใช้งานและตรวจสอบให้แน่ใจว่าไม่มีสัญญา EOF ที่ใช้งานอ้างอิงในส่วนรหัส

EIP-4200: EOF - การกระโดดสัมพัทธ์คงที่ (EOF - การกระโดดสัมพัทธ์คงที่)

EIP-4200 นำเสนอ opcodes เฉพาะ EOF ตัวแรก: RJUMP, RJUMPI และ RJUMPV ซึ่งเข้ารหัสปลายทางเป็นค่าทันทีที่มีการเซ็นชื่อ JUMP opcodes ใหม่เหล่านี้สามารถใช้โดยคอมไพเลอร์เพื่อเพิ่มประสิทธิภาพ gas overhead เนื่องจากไม่จำเป็นต้องใช้การวิเคราะห์ jumpdest รันไทม์ ซึ่งจำเป็นสำหรับ opcodes JUMP & JUMPI ที่มีอยู่

EIP-4750: EOF - ฟังก์ชัน (ฟังก์ชันที่นำเข้า EOF)

EIP-4750 ต่อยอดจาก 4200 อีกขั้น: ไม่อนุญาตให้ใช้ opcode ของ JUMP & JUMPI และเพิ่มทางเลือกสำหรับฟังก์ชัน RJUMP, RJUMPI และ RJUMPV ที่ไม่สามารถทำซ้ำได้ โดยแนะนำส่วนของฟังก์ชันเฉพาะใน EOF bytecode ที่สามารถข้ามไปยังจาก เรียกใช้ และส่งคืนโดยใช้ opcode JUMPF, CALLF และ RETF ใหม่ตามลำดับ

EIP-5450: EOF - การตรวจสอบความถูกต้องของสแต็ก (EOF - การตรวจสอบความถูกต้องของสแต็ก)

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

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

การถอน Beacon Chain

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

ในระดับสูง กลไกการถอนมีดังนี้:

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

Have a balance above 32 ETH (i.e. have accrued validator rewards)

Are withdrawable (i.e. have fully exited the validator set)

ยอดคงเหลือมากกว่า 32 ETH (นั่นคือได้รับรางวัลผู้ตรวจสอบแล้ว)

สามารถถอนได้ (ถอนได้ นั่นคือ ถอนออกจากชุดเครื่องมือตรวจสอบความถูกต้องแล้ว)

From these, the validator will create a list of withdrawals to be included in their ExecutionPayload. Each item in that list contains the following:

เครื่องมือตรวจสอบความถูกต้องจะสร้างรายการการถอนเงินจากเครื่องมือตรวจสอบความถูกต้องเหล่านี้เพื่อบรรจุลงใน ExecutionPayload แต่ละรายการในรายการประกอบด้วยสิ่งต่อไปนี้:

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

ValidatorIndex: ดัชนีตัวตรวจสอบที่มีการเพิ่มยอดคงเหลือ

ExecutionAddress: ที่อยู่ ETH ของชั้นการดำเนินการซึ่งควรส่งการถอน

จำนวนเงิน: จำนวนเงินที่ส่งไปยัง ExecutionAddress จำนวนเงินนี้วัดเป็น gwei (ไม่ใช่ wei)

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

นอกจากนี้ยังมีรายละเอียดที่น่าสังเกต:

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

เพื่อให้ดำเนินการถอนได้ ผู้ตรวจสอบจะต้องใช้โทเค็น 0x01 ซึ่งแสดงด้วยที่อยู่ ETH อนุญาตเฉพาะข้อมูลประจำตัวคู่คีย์ BLS 0x00 เมื่อสายบีคอนเริ่มทำงาน เพื่อเริ่มต้นการถอน ผู้ตรวจสอบความถูกต้องด้วยข้อมูลประจำตัว 0x00 จะต้องลงนามในข้อความ BLSToExecutionChange เหล่านี้จะเปิดใช้งานในการอัปเกรด Capella จะมีเครื่องมือต่างๆ ที่ใช้ในการลงนามข้อความนี้ และตัวตรวจสอบความถูกต้องสามารถคาดหวังการสนับสนุนและแบบฝึกหัดสำหรับเครื่องมือเหล่านี้ได้

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

ตามปกติ ก่อนที่ mainnet จะเริ่มใช้งานจริง จะมี testnet และ testnet สำหรับนักพัฒนาหลายตัว (บางทีอาจเป็น testnet ใหม่ด้วยซ้ำ!) เพื่อให้ตัวตรวจสอบความถูกต้องทำงานและขจัดข้อบกพร่อง

ชื่อระดับแรก

แคนคูนอัพเกรด

เนื่องจากเนื้อหาของการอัปเกรดในเซี่ยงไฮ้เต็มแล้ว EIP (CFI) จำนวนมากที่ได้รับการพิจารณาให้อัปเกรดจึงไม่สามารถเข้าสู่การอัปเกรดในเซี่ยงไฮ้ได้ ทีมลูกค้าเริ่มหารือกันว่า EIP ใดควรได้รับการพิจารณาสำหรับการอัปเกรดครั้งต่อไป: การอัปเกรด Cancun (ชื่อเลเยอร์ที่สอดคล้องต้องกัน)

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

cancun.md ถูกสร้างขึ้นตามหลักการของการอัปเกรดเพื่อใช้ชื่อเมืองที่โฮสต์ Devcon ซึ่งรวม EIP-4844 ไว้ในการอัปเกรดอย่างเป็นทางการ

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

พิธี KZG

อีกสิ่งหนึ่งที่เกี่ยวข้องกับการอัปเกรด Cancun คือพิธี KZG ซึ่งเป็นข้อกำหนดของ EIP-4844

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

ชื่อระดับแรก

กระบวนการอัปเกรดหลังการควบรวมกิจการ

ตามที่กล่าวไว้ในการอัปเดตก่อนหน้านี้ หลังจากการควบรวมกิจการ การประสานกระบวนการอัปเกรดของ Ethereum ที่ชั้นการดำเนินการและชั้นฉันทามติถือเป็นงานค้างที่สำคัญ ในระดับสูง เลเยอร์การดำเนินการใช้ Yellow Paper & EIP เพื่อระบุการแก้ไข ในขณะที่เลเยอร์ฉันทามติใช้ข้อมูลจำเพาะของ Python ที่ปฏิบัติการได้

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

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

ด้วยการเปิดตัวข้อมูลจำเพาะของ Ethereum Execution Layer เราหวังว่าจะปิดช่องว่างนี้จากมุมมองของเลเยอร์การดำเนินการ และด้วยการโต้เถียงของกระบวนการบางอย่าง เราอาจสามารถรับ EIP เข้าสู่กระบวนการชั้นฉันทามติได้!

ที่กล่าวว่า เมื่อมีการหารือและสรุปขอบเขตของการอัปเกรดเซี่ยงไฮ้ เป็นที่ชัดเจนว่าอาจมีส่วนอื่นของกระบวนการขาดหายไป นั่นคือการให้ชุมชนแสดงความพอใจต่อการเปลี่ยนแปลง และมีส่วนร่วมในการอภิปรายเกี่ยวกับขอบเขตโดยรวมของการอัปเกรด (แทนที่จะเป็น EIP แต่ละรายการ) อภิปรายว่า EIP อยู่ที่ไหนและกำหนดให้เป็นส่วนหนึ่งของการตัดสินใจในการประชุม AllCoreDevs และ Consensus Layer

ยังไม่ชัดเจนว่าจะเป็นอย่างไร - ฉันชอบที่จะรับข้อเสนอแนะ! — แต่ด้วยจำนวนผู้มีส่วนได้ส่วนเสียที่เข้าร่วมอย่างแข็งขันในการเปลี่ยนแปลงโปรโตคอลและจำนวนโดเมนที่ได้รับผลกระทบจากการเปลี่ยนแปลงเลเยอร์ที่เพิ่มขึ้น เราจึงต้องการบางอย่างอย่างชัดเจน

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

ชื่อระดับแรก

อัพเดทโปรโตคอลกิลด์

ด้วยการนำร่องของ Protocol Guild (PG) ไปได้ครึ่งทาง พวกเขาได้ออกรายงานเพื่อดูว่าสิ่งต่างๆ ดำเนินไปอย่างไรและกำลังคิดเกี่ยวกับสิ่งต่อไปสำหรับโครงการ

โปรดทราบว่า PG เป็นกลไกการระดมทุนที่ไม่ได้รับอนุญาตสำหรับนักพัฒนาไคลเอนต์ Ethereum Layer 1 นักวิจัยโปรโตคอล และผู้ให้การสนับสนุนเช่นคุณ

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

รายงานชั่วคราวของนักบินสรุปไว้ในทวีตนี้ นี่คือไฮไลท์บางส่วน

นักบินระดมทุนได้ 9.7 ล้านดอลลาร์จากองค์กรต่างๆ เช่น Lido, Uniswap, ENS, NounsDAO และ MolochDAO รวมถึงบางคนที่บริจาคเป็นประจำ (ขอบคุณ Tetranode!) - ขอบคุณทุกคนที่ทำให้สิ่งนี้เป็นไปได้!

PG มีสมาชิก 90 คนในตอนเปิดตัว และตอนนี้มี 128 คน โดยมีเงิน 5 ล้านเหรียญระหว่างพวกเขา

โดยเฉลี่ยแล้ว สมาชิกแต่ละคนจะได้รับ $39,000 โดยมีขั้นต่ำ $13,000 และสูงสุด $79,000

สถาปัตยกรรมของ PG กำลังเปลี่ยนแปลง จะรองรับ L2 และไม่จำเป็นต้องใช้หลายลายเซ็นเพื่ออัปเดตน้ำหนัก

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

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

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

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

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

ชื่อระดับแรก

ติดตาม

สรุปปี 2022... ช่างเป็นปีที่ไม่ธรรมดาจริงๆ! สามเดือนที่ผ่านมาเราไม่ได้รวมกัน! เมื่อ Ethereum มี Proof of Stake ทำงานอยู่เบื้องหลังอย่างเงียบๆ โฟกัสได้เปลี่ยนไปที่ธุรกรรมในอนาคต

เมื่อคุณกลับมาในเดือนมกราคม คุณสามารถคาดหวัง:

Shanghai/Capella อัพเกรด Developer Testnet และ Shadow Fork

พิธีเปิด KZG

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

นักบินของกิลด์โปรโตคอลจะสิ้นสุดลง และเราจะประกาศโครงสร้างหลังจากนักบิน

ขอบคุณที่อ่าน! และขอขอบคุณทุกคนที่สละเวลาปรับปรุง Ethereum ในปีที่ผ่านมา - เราประสบความสำเร็จมากมาย

ลิงค์ต้นฉบับ

ลิงค์ต้นฉบับ