Vitalik Buterin ยอมรับข้อผิดพลาดในการออกแบบที่ใหญ่ที่สุดของเขาตั้งแต่ปี 2017 – แล้ว Ethereum ของคุณมีความเสี่ยงหรือไม่?
Vitalik Buterin กล่าวว่าเขาไม่เห็นด้วยกับทวีตในปี 2017 ของเขาอีกต่อไปที่ลดความสำคัญของความจำเป็นที่ผู้ใช้ต้องตรวจสอบ Ethereum แบบ end-to-end ด้วยตัวเอง
สัปดาห์นี้ เขาโต้แย้งว่าเครือข่ายควรปฏิบัติต่อการตรวจสอบแบบ self-hosted ว่าเป็นช่องทางหลบหนีที่ไม่อาจต่อรองได้เมื่อสถาปัตยกรรมมีความเบาและเป็นแบบโมดูลาร์มากขึ้น
จุดยืนเดิมของ Buterin เกิดจากการถ่ายเถียงเรื่องการออกแบบว่าบล็อกเชนควรบันทึกสถานะบนเชนหรือปฏิบัติต่อสถานะว่าเป็น "สิ่งที่บอกเป็นนัย" ซึ่งสามารถสร้างใหม่ได้เฉพาะโดยการเล่นธุรกรรมที่เรียงลำดับซ้ำเท่านั้น
แนวทางของ Ethereum การวาง state root ในแต่ละ block header และสนับสนุนการพิสูจน์แบบ Merkle ช่วยให้ผู้ใช้สามารถพิสูจน์ยอดคงเหลือเฉพาะ โค้ดสัญญา หรือค่าการจัดเก็บโดยไม่ต้องดำเนินการประวัติทั้งหมดซ้ำ ตmindที่ผู้ใช้ยอมรับความถูกต้องของฉันทามติของเชนภายใต้สมมติฐานส่วนใหญ่ที่ซื่อสัตย์
ในโพสต์ใหม่ของเขา Buterin ปรับกรอบการแลกเปลี่ยนนั้นว่าไม่สมบูรณ์ในทางปฏิบัติ เพราะยังคงสามารถบังคับผู้ใช้ให้เลือกระหว่างการเล่นเชนทั้งหมดซ้ำหรือเชื่อใจตัวกลางเช่นผู้ดำเนินการ RPC โฮสต์ข้อมูลเก็บถาวร หรือบริการพิสูจน์
การกลับตัวของ Vitalik ในการตรวจสอบประวัติบล็อกเชนส่วนบุคคล
เขายึดการเปลี่ยนแปลงไว้ในสองการเปลี่ยนแปลง: ความเป็นไปได้และความเปราะบาง
ในด้านความเป็นไปได้ Buterin เขียนว่าการพิสูจน์แบบ zero-knowledge ตอนนี้เสนอเส้นทางในการตรวจสอบความถูกต้องโดยไม่ต้อง "ดำเนินการธุรกรรมทุกรายการซ้ำตามตัวอักษร"
ในปี 2017 เขาโต้แย้งว่าสิ่งนี้จะผลักดัน Ethereum ไปสู่ความจุที่ต่ำกว่าเพื่อให้การตรวจสอบอยู่ในระยะที่เข้าถึงได้
การเปลี่ยนแปลงมีความสำคัญเพราะแผนงานสาธารณะของ Ethereum ปฏิบัติต่อ ZK มากขึ้นว่าเป็นพื้นฐานการตรวจสอบได้ โดย ethereum.org กำหนดกรอบการพิสูจน์แบบ zero-knowledge เป็นวิธีรักษาคุณสมบัติด้านความปลอดภัยในขณะที่ลดสิ่งที่ผู้ตรวจสอบต้องคำนวณ
งานในทิศทาง "ZK-light-client" ยังชี้ไปสู่โมเดลที่อุปกรณ์สามารถซิงค์โดยใช้การพิสูจน์แบบกระชับแทนที่จะเชื่อใจเกตเวย์ที่ออนไลน์ตลอดเวลา
ในด้านความเปราะบาง Buterin ระบุโหมดความล้มเหลวที่อยู่นอกโมเดลภัยคุกคามที่ชัดเจน: เครือข่าย p2p ที่เสื่อมโทรม บริการที่มีอายุยาวนานปิดตัวลง การกระจุกตัวของตัวตรวจสอบที่เปลี่ยนความหมายในทางปฏิบัติของ "ส่วนใหญ่ที่ซื่อสัตย์" และแรงกดดันการกำกับดูแลแบบไม่เป็นทางการที่เปลี่ยน "โทรหาผู้พัฒนา" ให้เป็นทางออกสุดท้าย
เขายก Tornado Cash เป็นตัวอย่างของการกดดันการเซ็นเซอร์ว่าตัวกลางสามารถจำกัดการเข้าถึงได้อย่างไร โดยโต้แย้งว่าตัวเลือกสุดท้ายของผู้ใช้ควรเป็น "ใช้เชนโดยตรง"
กรอบการทำงานนั้นสอดคล้องกับการอภิปรายที่กว้างขึ้นเกี่ยวกับการเสริมความแข็งแกร่งของเลเยอร์พื้นฐานของ Ethereum และจำกัดการเปลี่ยนแปลง ท่ามกลางการผลักดันไปสู่ "การกลายเป็นฟอสซิล" ของโปรโตคอล
ในการบอกเล่าของ Buterin "กระท่อมบนภูเขา" ไม่ใช่วิถีชีวิตเริ่มต้น
มันเป็นทางเลือกสำรองที่น่าเชื่อถือที่เปลี่ยนแรงจูงใจ เพราะความรู้ที่ว่าผู้ใช้สามารถออกได้จะลดอำนาจของเลเยอร์บริการเดียวใดๆ
ข้อโต้แย้งนั้นเกิดขึ้นในขณะที่ Ethereum ลดสิ่งที่โหนดธรรมดาคาดว่าจะจัดเก็บ ในขณะที่เรื่องราวการตรวจสอบของเครือข่ายต้องก้าวตามให้ทัน
การใช้และประวัติของ Ethereum client
Execution clients กำลังเคลื่อนไปสู่การหมดอายุประวัติบางส่วน และ Ethereum Foundation กล่าวว่าผู้ใช้สามารถลดการใช้ดิสก์ประมาณ 300–500 GB โดยลบข้อมูลบล็อกก่อน Merge ทำให้โหนดอยู่ในระยะที่เข้าถึงได้บนดิสก์ 2 TB
ในขณะเดียวกัน light clients สะท้อนโมเดลความไว้วางใจที่เป็นทางการที่ปรับให้เหมาะสมสำหรับอุปกรณ์ที่มีทรัพยากรต่ำแล้ว โดยอาศัยคณะกรรมการซิงค์ที่มีตัวตรวจสอบ 512 ตัวที่เลือกทุกๆ 1.1 วันโดยประมาณ
พารามิเตอร์เหล่านั้นทำให้การตรวจสอบ light-client ใช้งานได้ในระดับใหญ่
อย่างไรก็ตาม พวกเขายังรวมศูนย์ประสบการณ์ผู้ใช้รอบความพร้อมใช้งานของข้อมูลที่ถูกต้องและรีเลย์ที่ทำงานได้ดีเมื่อสภาวะแย่ลง
งาน "statelessness" ระยะยาวของ Ethereum มุ่งหวังลดความจำเป็นที่โหนดต้องถือสถานะขนาดใหญ่ในขณะที่รักษาการตรวจสอบบล็อกไว้
Ethereum.org เตือนว่า "statelessness" เป็นชื่อที่ผิด โดยแยกรูปแบบที่อ่อนแอออกจากการออกแบบที่แข็งแกร่งกว่าที่ยังคงเป็นการวิจัย รวมถึง state expiry
Verkle trees อยู่ภายในแผนนั้นเพราะพวกเขาลดขนาดการพิสูจน์และถูกวางตำแหน่งเป็นขั้นตอนสำคัญที่เปิดใช้งานการตรวจสอบโดยไม่ต้องจัดเก็บสถานะขนาดใหญ่ในเครื่อง
เมื่อภาระการจัดเก็บมากขึ้นเปลี่ยนไปสู่ภายนอก ไม่ว่าจะเป็นโฮสต์ประวัติเฉพาะทางหรือเครือข่ายข้อมูลอื่นๆ เรื่องราวความปลอดภัยจะกลายเป็นเรื่องของใครสามารถจัดเก็บทุกอย่างน้อยลงและเป็นเรื่องของใครสามารถตรวจสอบความถูกต้องอย่างอิสระและเรียกข้อมูลที่ต้องการเมื่อเส้นทางเริ่มต้นล้มเหลวมากขึ้น
| สิ่งที่กำลังเปลี่ยนแปลง | เหตุใดจึงสำคัญสำหรับการตรวจสอบ | พารามิเตอร์หรือตัวเลขที่เป็นรูปธรรม |
|---|---|---|
| การสนับสนุนการหมดอายุประวัติบางส่วนใน execution clients | การจัดเก็บในเครื่องน้อยลงสามารถเพิ่มการพึ่งพาความพร้อมใช้งานประวัติภายนอก เว้นแต่เส้นทางการเรียกข้อมูลและการตรวจสอบจะยังเปิดอยู่ | การลดดิสก์ประมาณ 300–500 GB "สบาย" บนดิสก์ 2 TB |
| โมเดลความไว้วางใจของ PoS light client | การตรวจสอบทรัพยากรต่ำอาศัยลายเซ็นของคณะกรรมการและความพร้อมใช้งานข้อมูลผ่านเพียร์หรือบริการ | คณะกรรมการซิงค์ที่มีตัวตรวจสอบ 512 ตัว หมุนเวียนทุกๆ 1.1 วันโดยประมาณ |
| Verkle trees เป็นตัวเปิดใช้งาน stateless-client | การพิสูจน์ที่เล็กกว่าสามารถทำให้การตรวจสอบด้วยสถานะที่จัดเก็บน้อยลงใช้งานได้จริงมากขึ้น | กรอบแผนงานผูก Verkle trees เข้ากับเป้าหมายการตรวจสอบแบบ stateless |
| ความแตกต่างของแผนงาน Statelessness | แยกแนวทางระยะใกล้ออกจากรายการวิจัยเช่น state expiry | คำศัพท์ statelessness แบบอ่อนแอเทียบกับแบบแข็งแกร่ง |
| งานของ EF เกี่ยวกับรากฐานความปลอดภัย L1 zkEVM | ความเข้มงวดและความมั่นคงของระบบพิสูจน์กลายเป็นส่วนหนึ่งของเรื่องราวความปลอดภัยพื้นฐานของ Ethereum | เน้นการทำให้เสถียรและความพร้อมสำหรับการตรวจสอบอย่างเป็นทางการ |
ความหมายของสิ่งนี้ในอนาคต
ในช่วง 12–36 เดือนข้างหน้า คำถามในทางปฏิบัติคือการตรวจสอบจะแพร่กระจายออกไปหรือไม่เมื่อ Ethereum โอนภาระการจัดเก็บออกไปมากขึ้น หรือความไว้วางใจจะรวมกลุ่มรอบจุดคอขวดบริการใหม่
เส้นทางหนึ่งคือกระเป๋าเงินและโครงสร้างพื้นฐานเปลี่ยนจาก "เชื่อใจ RPC" เป็น "ตรวจสอบการพิสูจน์" ในขณะที่การผลิตการพิสูจน์รวมตัวเข้าสู่ชุดกองที่ปรับให้เหมาะสมเล็กๆ ที่ยากต่อการทำซ้ำ เคลื่อนย้ายการพึ่งพาจากผู้ให้บริการระดับหนึ่งไปยังอีกระดับหนึ่ง
เส้นทางอื่นคือการตรวจสอบแบบใช้การพิสูจน์กลายเป็นเรื่องธรรมดา ด้วยการใช้งานการพิสูจน์ซ้ำซ้อนและเครื่องมือที่ช่วยให้ผู้ใช้สลับผู้ให้บริการหรือตรวจสอบในเครื่องเมื่อปลายทางเซ็นเซอร์ เสื่อมสภาพ หรือหายไป สอดคล้องกับความพยายามที่มุ่งสู่กระแสการตรวจสอบที่มีน้ำหนักเบา
เส้นทางที่สามคือการตัดแต่งและความเป็นโมดูลาร์ก้าวหน้าเร็วกว่า UX การตรวจสอบ ทำให้ผู้ใช้มีตัวเลือกที่ใช้งานได้น้อยลงในระหว่างการหยุดทำงานหรือเหตุการณ์การเซ็นเซอร์
นั่นจะทำให้ "กระท่อมบนภูเขา" เป็นจริงในทางปฏิบัติสำหรับส่วนที่แคบของเครือข่ายเท่านั้น
Buterin กำหนดกรอบกระท่อมเป็น BATNA ของ Ethereum ไม่ค่อยถูกใช้แต่พร้อมใช้งานเสมอ เพราะการมีอยู่ของตัวเลือกพึ่งตนเองจำกัดเงื่อนไขที่กำหนดโดยตัวกลาง
เขาปิดท้ายด้วยการโต้แย้งว่าการรักษาทางเลือกสำรองนั้นเป็นส่วนหนึ่งของการรักษา Ethereum เอง
โพสต์ Vitalik Buterin ยอมรับความผิดพลาดการออกแบบที่ใหญ่ที่สุดของเขาตั้งแต่ปี 2017 – แล้ว Ethereum ของคุณมีความเสี่ยงหรือไม่? ปรากฏครั้งแรกบน CryptoSlate
คุณอาจชอบเช่นกัน
สวิส อินเตอร์เนชั่นแนล เจมแล็บ เปิดตัววิธีการให้คะแนนอัญมณีด้วย AI
United Health Products ได้รับการอนุมัติจาก FDA สำหรับแผนการศึกษาทางคลินิกใหม่เพื่อตอบสนองต่อจดหมายเตือน
