ทบทวนบทความขนาดยาวของ Vitalik: Ethereum "เส้นทางที่ยังไม่เคยเดินทาง"
ชื่อเรื่องเดิม: "
ชื่อเรื่องเดิม: "The roads not taken》
Wu กล่าวว่า blockchainWu กล่าวว่า blockchain
ชุมชนการพัฒนา Ethereum ได้ทำการตัดสินใจมากมายในช่วงแรก ๆ ของ Ethereum ซึ่งมีผลกระทบอย่างมากต่อวิถีของโครงการ ในบางกรณี นักพัฒนา ethereum ได้ตัดสินใจอย่างมีสติเพื่อปรับปรุงจุดที่เราคิดว่า bitcoin เป็นปัญหา ที่อื่น เรากำลังสร้างสิ่งใหม่ทั้งหมด และเราแค่ต้องคิดอะไรบางอย่างเพื่อเติมเต็มช่องว่าง แต่ก็มีหลายอย่างให้เลือก นอกจากนี้ยังมีจุดที่เราต้องทำการแลกเปลี่ยนระหว่างสิ่งที่ซับซ้อนกว่าและสิ่งที่ง่ายกว่า บางครั้งเราเลือกสิ่งที่ง่ายกว่า แต่บางครั้งเราเลือกสิ่งที่ซับซ้อนกว่า
ชื่อเรื่องรอง
เราควรจะใช้กลไก PoS ที่ง่ายกว่านี้หรือไม่?
กลไก Gasper PoS ที่ Ethereum กำลังจะรวมเป็นระบบที่ซับซ้อน แต่ก็เป็นระบบที่ทรงพลังมากเช่นกัน คุณสมบัติบางอย่างรวมถึง:
การยืนยันแบบบล็อกเดียวที่แข็งแกร่งมาก: เมื่อธุรกรรมรวมอยู่ในบล็อก โดยปกติภายในไม่กี่วินาที การบล็อกจะเสร็จสิ้นเว้นแต่โหนดจำนวนมากจะไม่ซื่อสัตย์ หรือมีเวลาแฝงของเครือข่ายมาก ซึ่งไม่สามารถย้อนกลับได้
ขั้นสุดท้ายทางเศรษฐกิจ: เมื่อการบล็อกเสร็จสิ้นแล้ว จะไม่สามารถย้อนกลับได้ เว้นแต่ผู้โจมตีจะทนต่อการสูญเสีย ETH หลายล้านรายการและถูกปรับ
รางวัลที่คาดเดาได้มาก: ผู้ตรวจสอบความถูกต้องจะได้รับรางวัลทุกยุคทุกสมัย (6.4 นาที)
รองรับจำนวนผู้ตรวจสอบความถูกต้องที่สูงมาก: Ethereum Beacon Chain ไม่เหมือนกับเชนอื่น ๆ ส่วนใหญ่ที่มีคุณสมบัติข้างต้น Ethereum Beacon Chain รองรับผู้ตรวจสอบความถูกต้องหลายแสนคน (เช่น: Tendermint ให้การสิ้นสุดที่เร็วกว่า Ethereum แต่รองรับผู้ตรวจสอบความถูกต้องหลายร้อยคนเท่านั้น)
แต่การสร้างระบบที่มีคุณสมบัติเหล่านี้เป็นเรื่องยาก ต้องใช้เวลาหลายปีในการวิจัย หลายปีของการทดลองที่ล้มเหลว และบ่อยครั้งต้องใช้ความพยายามอย่างมาก โดยมีผลลัพธ์สุดท้ายที่ค่อนข้างซับซ้อน
หากนักวิจัยของเราไม่ต้องกังวลมากเกี่ยวกับความเห็นพ้องต้องกันและมีเวลาว่างมากขึ้นในการคิด บางที อาจจะมีการคิดค้นการสรุปผลในปี 2559 สิ่งนี้ทำให้เราคิดว่า: เราควรต้องการมาตรฐานที่สูงเช่นนี้สำหรับ PoS ของเราจริงหรือ เพราะแม้แต่ PoS ที่เรียบง่ายและอ่อนแอกว่าก็ยังเป็นการปรับปรุงอย่างมากจากสถานะ PoW ที่เป็นอยู่
หลายคนมีความเข้าใจผิดว่า PoS นั้นซับซ้อน แต่ในความเป็นจริงมีอัลกอริธึม PoS มากมายที่เกือบจะง่ายพอๆ PoS ของ NXT มีมาตั้งแต่ปี 2013 และน่าจะเป็นตัวเลือกที่พร้อมแล้ว แม้ว่าจะมีปัญหาอยู่บ้าง แต่ปัญหาเหล่านั้นได้รับการแก้ไขอย่างง่ายดาย และเราอาจมี PoS ที่ใช้งานได้พอสมควรตั้งแต่ปี 2017 หรือแม้กระทั่งตั้งแต่เริ่มต้น Gasper ซับซ้อนกว่าอัลกอริธึมเหล่านี้เพียงเพราะมันพยายามทำมากกว่านั้น แต่ถ้าเราไม่ตั้งเป้าหมายไว้สูงเกินไปตั้งแต่แรก เราสามารถเริ่มด้วยการมุ่งเน้นไปที่การบรรลุเป้าหมายที่จำกัดมากขึ้น
ชื่อเรื่องรอง
การสลายตัวของเศษ
Ethereum Sharding มีทิศทางที่น้อยลงและซับซ้อนน้อยลง นับตั้งแต่การวิจัยเริ่มขึ้นในปี 2014 ขั้นแรก เรามี Shards ที่ซับซ้อนพร้อมการดำเนินการในตัวและการทำธุรกรรมข้าม Shard จากนั้น เราลดความซับซ้อนของโปรโตคอลโดยเปลี่ยนความรับผิดชอบให้กับผู้ใช้มากขึ้น ซึ่งผู้ใช้ต้องจ่ายแก๊สสำหรับ Shards ทั้งสองแยกกัน จากนั้นเราเปลี่ยนไปใช้ แผนงานที่เน้นการรวมศูนย์ซึ่งจากมุมมองของโปรโตคอล เศษเป็นเพียงเศษข้อมูล ในที่สุด ผ่าน Danksharding ตลาดค่าธรรมเนียมของชิ้นส่วนจะรวมเป็นหนึ่งทั้งหมด และการออกแบบขั้นสุดท้ายจะดูเหมือนห่วงโซ่ที่ไม่ใช่ชิ้นส่วน แต่ที่นี่ การสุ่มตัวอย่างความพร้อมใช้งานของข้อมูลจะเปิดใช้งานการตรวจสอบชิ้นส่วน
แต่ถ้าเราใช้เส้นทางที่ตรงกันข้ามล่ะ? มีนักวิจัย Ethereum บางคนที่เจาะลึกเข้าไปในระบบชาร์ดดิ้งที่ซับซ้อนมากขึ้น: ชาร์ดจะทำหน้าที่เป็นเชน จะมีกฎการเลือกส้อม โดยที่เชนลูกขึ้นอยู่กับเชนแม่ และข้อความข้ามชาร์ดจะถูกกำหนดเส้นทางโดยโปรโตคอล เครื่องมือตรวจสอบความถูกต้อง จะหมุนเวียนระหว่างเศษ และแม้แต่ DApps ก็จะรับโหลดที่สมดุลระหว่างเศษโดยอัตโนมัติ
ปัญหาของแนวทางนี้คือรูปแบบการแบ่งกลุ่มเหล่านี้ส่วนใหญ่เป็นแนวคิดและแบบจำลองทางคณิตศาสตร์ ในขณะที่ Danksharding เป็นข้อกำหนดเฉพาะที่สมบูรณ์และนำไปปฏิบัติได้เกือบทั้งหมด ดังนั้น ด้วยสถานการณ์และข้อจำกัดของ Ethereum การทำให้ Sharding ง่ายขึ้นและการแก้ความกำกวมเป็นสิ่งที่ถูกต้องอย่างแน่นอนในความคิดของฉัน ที่กล่าวว่า การวิจัยที่มีความทะเยอทะยานมากขึ้นยังมีบทบาทที่สำคัญมาก: ระบุทิศทางการวิจัยที่มีแนวโน้ม และแม้แต่แนวคิดที่ซับซ้อนมากก็มักจะมี"เรียบง่ายพอสมควร"ชื่อเรื่องรอง
การเลือกคุณสมบัติใน EVM
อันที่จริงแล้ว ยกเว้นการตรวจสอบความปลอดภัย ข้อกำหนด EVM โดยทั่วไปสามารถเปิดตัวได้ในช่วงกลางปี 2014 อย่างไรก็ตาม ในเดือนต่อๆ มา ณ เวลานั้น เรายังคงสำรวจคุณลักษณะใหม่อย่างต่อเนื่อง ซึ่งเราเชื่อว่าอาจมีความสำคัญอย่างยิ่งต่อบล็อกเชนแบบกระจายอำนาจ คุณสมบัติบางอย่างถูกเพิ่มเข้าไปใน EVM แต่บางอย่างไม่ได้เพิ่ม
เราพิจารณาที่จะเพิ่ม POST opcode แต่ตัดสินใจไม่เพิ่ม POST opcode ทำการโทรแบบอะซิงโครนัสและดำเนินการหลังจากการทำธุรกรรมเสร็จสมบูรณ์
เราพิจารณาที่จะเพิ่ม OPcode ของ ALARM แต่ตัดสินใจไม่เพิ่ม ALARM ทำหน้าที่เหมือนกับ POST ยกเว้นว่าจะทำการเรียกแบบอะซิงโครนัสในบางบล็อกในอนาคต ทำให้สัญญาสามารถกำหนดการดำเนินการได้
เราได้เพิ่มบันทึกซึ่งอนุญาตให้สัญญาส่งออกบันทึกที่ไม่แตะสถานะ แต่สามารถตีความได้โดยอินเทอร์เฟซและกระเป๋าเงินของ DApp เป็นที่น่าสังเกตว่าเรายังพิจารณาให้การถ่ายโอน ETH ปล่อยบันทึก แต่ตัดสินใจที่จะไม่ทำ โดยอ้างถึง"ผู้คนจะเปลี่ยนไปใช้กระเป๋าเงินสัญญาอัจฉริยะในไม่ช้า"。
เราพิจารณาที่จะขยาย SSTORE ให้รองรับอาร์เรย์แบบไบต์ แต่ตัดสินใจไม่ทำเช่นนั้นเนื่องจากความซับซ้อนและความกังวลด้านความปลอดภัย
เราได้เพิ่มคอมไพล์ล่วงหน้าซึ่งเป็นสัญญาที่ใช้การนำไปใช้งานแบบเนทีฟเพื่อดำเนินการเข้ารหัสแบบพิเศษ ซึ่งถูกกว่าการดำเนินการใน EVM มาก
เราครุ่นคิดถึงค่าเช่าของรัฐในช่วงหลายเดือนนับตั้งแต่เริ่มใช้งานจริง แต่ก็ไม่เคยคิดรวมอยู่ด้วย มันซับซ้อนเกินไป ปัจจุบันมีการสำรวจแผนการหมดอายุสถานะที่ดีขึ้น แม้ว่าการตรวจสอบแบบไร้สัญชาติและการแยกผู้เสนอ/ผู้สร้าง (PBS) หมายความว่าตอนนี้มีความสำคัญต่ำกว่ามาก
ปัจจุบัน การตัดสินใจส่วนใหญ่ที่จะไม่เพิ่มฟังก์ชันกลายเป็นการตัดสินใจที่ดีมาก ไม่มีเหตุผลที่ชัดเจนในการเพิ่ม POST opcode OPcode ของ ALARM นั้นยากที่จะนำไปใช้อย่างปลอดภัย: จะเกิดอะไรขึ้นถ้าทุกคนในบล็อก 1...9999 ตั้ง ALARM และรันโค้ดจำนวนมากที่บล็อก 100,000 การบล็อกนั้นจะใช้เวลาหลายชั่วโมงในการดำเนินการหรือไม่ การดำเนินการตามกำหนดเวลาบางอย่างจะถูกพุชไปยังบล็อกภายหลังหรือไม่ แต่ถ้าเป็นเช่นนั้น ALARM จะรับประกันอะไร SSTORE ของอาร์เรย์ไบต์นั้นยากที่จะทำได้อย่างปลอดภัยและจะขยายขนาดของพยานที่เลวร้ายที่สุดอย่างมาก
ชื่อเรื่องรอง
ทางเลือกอื่นในการเข้าสู่ระบบ
LOG สามารถทำได้สองวิธี
เราสามารถทำให้การโอน ETH ส่ง LOG โดยอัตโนมัติ สิ่งนี้จะช่วยให้การแลกเปลี่ยนและผู้ใช้อื่น ๆ จำนวนมากไม่ต้องพยายามและปัญหาข้อบกพร่องของซอฟต์แวร์ และจะเร่งให้ทุกคนพึ่งพา LOG ซึ่งจะช่วยให้มีการนำกระเป๋าสัญญาอัจฉริยะมาใช้
เราสามารถทำได้อย่างสมบูรณ์โดยไม่ต้องใช้ OPcode ของ LOG และเปลี่ยนเป็น ERC: จะมีสัญญามาตรฐานซึ่งมีฟังก์ชัน submitLog และใช้เทคนิคของสัญญาฝาก Ethereum เพื่อคำนวณราก Merkle ของบันทึกทั้งหมดในบล็อก EIP-2929 หรือที่เก็บข้อมูลทั้งบล็อก (เทียบเท่ากับ TSTORE แต่ถูกล้างหลังจากบล็อก) จะทำให้ราคานี้ถูกกว่า
เราพิจารณาตัวเลือกแรกอย่างจริงจัง แต่ปฏิเสธ เหตุผลหลักคือการบันทึกมาจากรหัส LOG เท่านั้นซึ่งง่ายกว่า นอกจากนี้ เรายังคาดไว้อย่างผิดๆ ว่าผู้ใช้ส่วนใหญ่จะโอนย้ายไปยังกระเป๋าเงินสัญญาอัจฉริยะอย่างรวดเร็ว ซึ่งสามารถใช้ opcodes เพื่อบันทึกการถ่ายโอนได้อย่างชัดเจน
เราไม่ได้พิจารณาตัวเลือกที่สอง แต่เมื่อมองย้อนกลับไป มันเป็นตัวเลือกจริงๆ ข้อเสียเปรียบหลักของวิธีที่สองคือการขาดกลไกตัวกรอง Bloom (ตัวกรอง Bloom) สำหรับการสแกนบันทึกอย่างรวดเร็ว แต่กลับกลายเป็นว่ากลไกการกรองของ Bloom นั้นช้าเกินไปและไม่เป็นมิตรกับ DApps ดังนั้นตอนนี้ผู้คนจำนวนมากขึ้นจึงใช้ TheGraph ในการสืบค้นข้อมูล
โดยรวมแล้ว วิธีการใด ๆ เหล่านี้มีศักยภาพที่จะเหนือกว่าสภาพที่เป็นอยู่ การไม่อยู่ใน LOG จะทำให้สิ่งต่างๆ ง่ายขึ้น แต่จะมีประโยชน์มากกว่าหากบันทึกการโอน ETH ทั้งหมดโดยอัตโนมัติหากอยู่ใน LOG
ชื่อเรื่องรอง
จะเกิดอะไรขึ้นหาก EVM ปัจจุบันใช้เส้นทางที่แตกต่างไปจากเดิมอย่างสิ้นเชิง
ในตอนเริ่มต้น EVM มีสองเส้นทางที่แตกต่างกันมากให้เลือก:
ทำให้ EVM เป็นภาษาระดับที่สูงขึ้น โดยมีโครงสร้างในตัว เช่น ตัวแปร คำสั่ง if ลูป และอื่นๆ
ทำให้ EVM เป็นสำเนาของเครื่องเสมือนที่มีอยู่ (LLVM, WASM เป็นต้น)
เส้นทางแรกไม่เคยถูกพิจารณาจริงๆ ความน่าสนใจของเส้นทางนี้คือสามารถทำให้คอมไพเลอร์ง่ายขึ้นและอนุญาตให้นักพัฒนาจำนวนมากขึ้นเขียนโค้ดโดยตรงใน EVM นอกจากนี้ยังทำให้โครงสร้างของ ZK-EVM ง่ายขึ้นอีกด้วย จุดอ่อนของวิธีการนี้คือทำให้โค้ด EVM มีโครงสร้างที่ซับซ้อนมากขึ้น: มันไม่ใช่รายการของ opcodes แบบธรรมดาอีกต่อไป แต่เป็นโครงสร้างข้อมูลที่ซับซ้อนมากขึ้นซึ่งต้องจัดเก็บด้วยวิธีใดวิธีหนึ่ง นั่นคือเราพลาดโอกาสที่จะได้รับสิ่งที่ดีที่สุดจากทั้งสองโลก: การเปลี่ยนแปลง EVM บางอย่างอาจให้ประโยชน์มากมายแก่เรา ในขณะที่ยังคงรักษาโครงสร้าง EVM พื้นฐานไว้เช่นเดิม: การปิดใช้งานการกระโดดแบบไดนามิก การเพิ่ม opcodes บางตัวที่ออกแบบมาเพื่อรองรับรูทีนย่อย (มิฉะนั้น โปรดดูที่: EIP -2315) การเข้าถึงหน่วยความจำจะได้รับอนุญาตเฉพาะในขอบเขตของคำขนาด 32 ไบต์ เป็นต้น
เส้นทางที่สองได้รับการแนะนำและปฏิเสธหลายครั้ง ข้อโต้แย้งที่สนับสนุนคืออนุญาตให้รวบรวมโปรแกรมจากภาษาที่มีอยู่ (C, Rust ฯลฯ ) ลงใน EVM มีข้อโต้แย้งอยู่เสมอว่า ด้วยข้อจำกัดเฉพาะของ Ethereum มันไม่ได้ให้ประโยชน์ใดๆ เลย:
คอมไพเลอร์สำหรับภาษาระดับสูงที่มีอยู่มักไม่สนใจขนาดโค้ดทั้งหมด ในขณะที่โค้ดบล็อกเชนต้องได้รับการปรับให้เหมาะสมอย่างมากเพื่อลดขนาดโค้ดทุกไบต์
เราต้องการการใช้งานเครื่องเสมือนหลายรายการ และกำหนดอย่างเคร่งครัดว่าไม่มีการใช้งานสองครั้งที่จัดการรหัสเดียวกันแตกต่างกัน การตรวจสอบความปลอดภัยและการยืนยันโค้ดที่เราไม่ได้เขียนทำได้ยากขึ้น
หากข้อกำหนด VM เปลี่ยนแปลง Ethereum จะต้องอัปเดตอยู่เสมอหรือไม่ซิงค์กันมากขึ้นเรื่อยๆ
ชื่อเรื่องรอง
ควรกระจายการจัดหา ETH แตกต่างกันหรือไม่?
อุปทานปัจจุบันของ ETH สามารถแสดงโดยกราฟของ Etherscan นี้:
ปัจจุบัน ประมาณครึ่งหนึ่งของ ETH ทั้งหมดถูกขายใน Ethereum Public Sale ซึ่งทุกคนสามารถส่ง BTC ไปยังที่อยู่ Bitcoin และการจัดสรรการจัดหา ETH เริ่มต้นจะคำนวณผ่านสคริปต์โอเพ่นซอร์ส ส่วนที่เหลือส่วนใหญ่ก็ถูกขุดเช่นกัน ETH 12 ล้าน ETH สีดำที่ทำเครื่องหมายว่า "อื่นๆ" นั้นแท้จริงแล้วเป็นส่วนก่อนการขุด จำนวนเงินที่แจกจ่ายระหว่างมูลนิธิ Ethereum และผู้ร่วมสนับสนุนโปรโตคอล Ethereum ประมาณ 100 ราย
มีการวิพากษ์วิจารณ์กระบวนการนี้หลักๆ อยู่ 2 ประการคือ
การขุดล่วงหน้าหรือกองทุน Ethereum ที่รับผิดชอบการเสนอขายต่อสาธารณะนั้นไม่มีความเป็นกลางที่น่าเชื่อถือ ที่อยู่ผู้รับบางแห่งได้รับการคัดเลือกด้วยตนเองผ่านกระบวนการปิด มูลนิธิ Ethereum จะต้องได้รับความไว้วางใจไม่ให้ใช้ประโยชน์จากรายได้จากการขายสาธารณะเพิ่มเติมผ่านการกู้ยืมเงินเพื่อรับ ETH มากขึ้น (เราไม่ทำ และไม่มีใครอ้างว่าเรามี แต่แม้กระทั่งข้อกำหนดที่ต้องเชื่อถือได้ก็ไม่พอใจ บางคน).
พรีมีนให้รางวัลแก่ผู้ร่วมให้ข้อมูลในช่วงแรกมากเกินไป เหลือน้อยเกินไปสำหรับผู้ร่วมให้ข้อมูลรายหลัง 75% ของการขุดล่วงหน้าถูกใช้เพื่อให้รางวัลแก่ผู้ร่วมให้ข้อมูลก่อนที่จะออนไลน์ และหลังจากออนไลน์แล้ว Ethereum Foundation จะเหลือเพียง 3 ล้าน ETH ในช่วง 6 เดือน ความต้องการขายเพื่อความอยู่รอดทำให้สต็อกเหลือประมาณ 1 ล้าน ETH
ในทางหนึ่ง ประเด็นเหล่านี้มีความเกี่ยวข้องกัน: ความปรารถนาที่จะลดการรับรู้ของการรวมศูนย์มีส่วนทำให้ส่วนควบคุมมีขนาดเล็กลง แต่ส่วนควบคุมส่วนหน้าที่มีขนาดเล็กลงจะระบายออกได้เร็วกว่า
นี่ไม่ใช่ทางออกเดียว Zcash ใช้วิธีการที่แตกต่างออกไป: 20% ของรางวัลบล็อกคงที่จะถูกจัดสรรให้กับชุดผู้รับแบบตายตัวในโปรโตคอลที่มีการเจรจาใหม่ทุก ๆ สี่ปี (จนถึงตอนนี้ สิ่งนี้เคยเกิดขึ้นมาแล้ว 1 ครั้ง) สิ่งนี้จะยั่งยืนกว่า แต่จะถูกวิพากษ์วิจารณ์อย่างรุนแรงว่าเป็นการรวมศูนย์มากเกินไป (ชุมชน Zcash ดูเหมือนจะยอมรับความเป็นผู้นำด้านเทคโนโลยีอย่างเปิดเผยมากกว่าชุมชน Ethereum)
เส้นทางทางเลือกที่เป็นไปได้คล้ายกับเส้นทางที่ได้รับความนิยมในโครงการ DeFi บางโครงการในปัจจุบัน"DAO from day 1"เส้นทาง. นี่คือข้อเสนอของมนุษย์ฟางที่เป็นไปได้:
เราตกลงที่จะจัดสรร 2 ETH จากรางวัลแต่ละบล็อกให้กับกองทุนพัฒนาเป็นเวลา 2 ปี
ใครก็ตามที่ซื้อ ETH ในการขายสาธารณะของ Ethereum สามารถลงคะแนนสำหรับการจัดสรรกองทุนเพื่อการพัฒนาที่พวกเขาชื่นชอบ (เช่น:"ในแต่ละรางวัลบล็อก 1ETH มอบให้กับ Ethereum Foundation 0.4ETH มอบให้กับทีมวิจัย Consensys และ 0.2ETH มอบให้กับ Vlad Zamfir..."）
ผู้รับการโหวตจะได้รับส่วนแบ่งกองทุนการพัฒนาเท่ากับค่ามัธยฐานของการโหวตของแต่ละคน โดยคิดเป็นสัดส่วนรวมเท่ากับ 2ETH ต่อบล็อก (ค่ามัธยฐานคือการป้องกันการซื้อขายด้วยตนเอง: หากคุณลงคะแนนให้ตัวเอง คุณจะได้รับอะไรน้อยกว่านั้น เว้นแต่คุณจะได้รับ อย่างน้อยครึ่งหนึ่งของผู้ซื้อรายอื่นที่จะพูดถึงคุณ)
การขายสาธารณะอาจดำเนินการโดยนิติบุคคลที่สัญญาว่าจะแจกจ่าย bitcoins ที่ได้รับระหว่างการขายสาธารณะในสัดส่วนเดียวกับกองทุนพัฒนา ETH (หรือเผามัน หากเราต้องการให้ชาว bitcoin มีความสุข) สิ่งนี้อาจนำไปสู่การระดมทุนจำนวนมากสำหรับ Ethereum Foundation และการระดมทุนจำนวนมากสำหรับกลุ่มที่ไม่ใช่ Ethereum Foundation (นำไปสู่การกระจายอำนาจมากขึ้นของระบบนิเวศ) ทั้งหมดนี้โดยไม่ทำลายความเป็นกลางที่น่าเชื่อถือหนึ่งส่วนน้อย ข้อเสียหลักคือแน่นอนว่าการลงคะแนนโทเค็นนั้นแย่มาก แต่ในทางปฏิบัติเราสามารถตระหนักได้ว่าปี 2014 ยังคงเป็นช่วงเวลาเริ่มต้นและเป็นอุดมคติ และข้อเสียที่เลวร้ายที่สุดของการลงคะแนนโทเค็นจะเกิดขึ้นหลังจากการขายสาธารณะสิ้นสุดลงเป็นเวลานาน จะเริ่มทำงาน
ชื่อเรื่องรอง
เราเรียนรู้อะไรได้บ้างจากทั้งหมดนี้
โดยทั่วไปแล้ว บางครั้งฉันรู้สึกว่าความท้าทายที่ยิ่งใหญ่ที่สุดของ Ethereum มาจากการสร้างสมดุลระหว่างสองวิสัยทัศน์: บล็อกเชนที่ให้ความสำคัญกับความปลอดภัยและความเรียบง่าย และแพลตฟอร์มที่มีประสิทธิภาพสูงและใช้งานได้จริงสำหรับการสร้างแอปพลิเคชันขั้นสูง ตัวอย่างมากมายข้างต้นเป็นเพียงแง่มุมเดียว: เราเหมือน Bitcoin มากขึ้นด้วยฟีเจอร์ที่น้อยลง หรือเราเป็นมิตรกับนักพัฒนามากกว่าด้วยฟีเจอร์ที่มากกว่า เรากังวลเกี่ยวกับการทำให้การระดมทุนของ dev เป็นกลางมากขึ้น เช่น Bitcoin หรือเรากังวลเกี่ยวกับการทำให้แน่ใจว่านักพัฒนาได้รับรางวัลเพียงพอที่จะทำให้ Ethereum ดีขึ้นตั้งแต่แรก?
ความฝันส่วนตัวของฉันคือการพยายามบรรลุวิสัยทัศน์ทั้งสองในเวลาเดียวกัน เลเยอร์ฐานซึ่งข้อกำหนดในแต่ละปีมีขนาดเล็กกว่าปีที่แล้ว และระบบนิเวศที่เป็นมิตรต่อนักพัฒนาที่แข็งแกร่งของแอปพลิเคชันขั้นสูงที่มีศูนย์กลางอยู่ที่โปรโตคอลเลเยอร์ 2 กล่าวคือ จะต้องใช้เวลานานกว่าจะไปถึงโลกในอุดมคติ และอาจเป็นประโยชน์อย่างยิ่งสำหรับเราที่จะตระหนักได้ชัดเจนยิ่งขึ้นว่าสิ่งนี้ต้องใช้เวลา และเราต้องพิจารณาการวางแผนเส้นทางทีละขั้นตอน
ทุกวันนี้ มีหลายสิ่งที่เราเปลี่ยนแปลงไม่ได้ แต่ก็มีหลายสิ่งที่เรายังคงเปลี่ยนแปลงได้ และยังคงมีเส้นทางที่มั่นคงในการปรับปรุงฟังก์ชันการทำงานและความเรียบง่าย บางครั้งเส้นทางก็คดเคี้ยว: เราจำเป็นต้องเพิ่มความซับซ้อนก่อนเพื่อเปิดใช้งานการชาร์ดดิ้ง ซึ่งจะทำให้เลเยอร์ 2 สามารถปรับขนาดได้จำนวนมากที่อยู่ด้านบนสุด การลดความซับซ้อนนั้นเป็นไปได้ และประวัติศาสตร์ของ Ethereum ก็ได้แสดงให้เห็นแล้ว
EIP-150 ทำให้การจำกัดความลึกของคอลสแต็กไม่เกี่ยวข้อง ซึ่งช่วยลดความกังวลด้านความปลอดภัยสำหรับนักพัฒนาสัญญา
EIP-161 แยกแนวคิดของ "บัญชีว่าง" ออกจากบัญชีที่มีฟิลด์เป็นศูนย์
EIP-3529 ลบกลไกการคืนเงินบางส่วน ทำให้ Gas token ไม่สามารถใช้งานได้อีกต่อไป
แนวคิดในไปป์ไลน์ เช่น ต้นไม้ Verkle ช่วยลดความซับซ้อนลงไปอีก แต่จะทำอย่างไรให้วิสัยทัศน์ทั้งสองนี้สมดุลกันในอนาคตเป็นคำถามที่เราควรเริ่มคิดอย่างแข็งขันมากขึ้น
