ความคิดเห็น: Eth2 เป็น Data Availability Engine

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

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

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

, ผู้แต่ง: Casey Detrio, ผู้แปล & ผู้พิสูจน์อักษร: Min Min & A Jian, ทำซ้ำโดย Odaily โดยได้รับอนุญาต

หมายเหตุบรรณาธิการ: ชื่อเดิมของบทความนี้คือ "Phase One and Done: eth2 as a data available engine" ณ เวลาที่เผยแพร่ (เมษายน 2019) ผู้เขียนตั้งใจที่จะเสนอแผนงานสำหรับ Eth2.0 เพื่อแทนที่ Phase 2 นั่นคือ หากใช้เฉพาะการแบ่งส่วนย่อยเพื่อให้แน่ใจว่าข้อมูลพร้อมใช้งาน ระบบดังกล่าวจะมีประโยชน์หรือไม่ และต้องเพิ่มส่วนใดบ้างเพื่อให้มีประโยชน์ น่าแปลกที่หนึ่งปีครึ่งที่แล้ว ผู้เขียนตระหนักว่าสำหรับระบบเช่น zk-rollup เลเยอร์ด้านล่างจะต้องรับประกันว่า "การดำเนินการของการเปลี่ยนสถานะและความพร้อมใช้งานของข้อมูลจะต้องถูกผูกมัดในระดับอะตอมเข้าด้วยกัน" ดังนั้นเลเยอร์พื้นฐานจะต้องมี ความสามารถในการดำเนินการแม้ว่าจะเป็นการดำเนินการแบบไร้สัญชาติที่เรียบง่ายก็ตาม ยิ่งกว่านั้น (ผู้เขียนยังชี้ให้เห็นผ่านการให้เหตุผลหลายชั้น) เพื่อให้แน่ใจว่าผู้ใช้ได้รับประสบการณ์ ส่วนหลัก ๆ ที่ยังขาดหายไปคือขั้นตอนการแยกส่วนข้อมูล ข้อตกลงการชำระเงิน (จุดเข้าใจทั้งสองนี้แม้ในปัจจุบันยังสามารถเรียกว่าล้ำสมัยหรือขั้นสูง) โปรโตคอลค่าธรรมเนียมยังขาดหายไปในข้อกำหนดระยะที่ 2

อย่างไรก็ตาม ผู้เขียนบทความนี้คือ Casey Detrio ซึ่งเป็นสมาชิกของทีม Ewasm และเคยให้แนวคิดมากมายสำหรับเฟส 2 มาก่อน เขายังเชื่อว่า Eth2 ควรได้รับการออกแบบโดยมีแกนหลักคือ "การรับประกันว่าสัญญา Eth1 สามารถ ดำเนินการตามปกติเมื่อ Eth2 มาถึง" .0. เขาเป็นนักพัฒนาที่ด้อยค่า

ปัจจุบัน ปัญหาคอขวดที่จำกัดปริมาณงาน Eth1 คือการเติบโตของสถานะ ดังนั้น หากเราต้องการปรับขนาด Ethereum ตามเหตุผล 1,000 เศษที่มีสถานะเป็นอิสระสามารถเพิ่มปริมาณงานได้ 1,000 เท่า

อย่างไรก็ตาม จากเส้นทาง Eth1.x นั้น Eth1.x ต้องการปรับเปลี่ยนครั้งใหญ่กับต้นทุนของทรัพยากรสองประเภท: ที่เก็บข้อมูล (ที่เก็บข้อมูล) และข้อมูลธุรกรรม (ข้อมูล tx) ปัจจุบันพื้นที่จัดเก็บมีราคาต่ำเกินไปและข้อมูลธุรกรรมมีราคาสูงเกินไป สิ่งนี้จะจูงใจให้นักพัฒนา dApp ใช้พื้นที่เก็บข้อมูลมากกว่าข้อมูลการทำธุรกรรมเมื่อเขียนสัญญา ทำให้พื้นที่เก็บข้อมูลกลายเป็นคอขวดของทรูพุต วิธีแก้ปัญหาที่เสนอคือการเพิ่มราคาของที่เก็บข้อมูลและลดราคาของข้อมูลธุรกรรม ด้วยการปรับค่าใช้จ่ายเหล่านี้ นักพัฒนาจะได้รับแรงจูงใจให้ใช้ข้อมูลธุรกรรมมากกว่าพื้นที่เก็บข้อมูล (กล่าวคือ พวกเขาจะเขียนสัญญาไร้สัญชาติมากขึ้นแทนที่จะเป็นสัญญาไร้สถานะ) ดังนั้น ในอนาคตอันใกล้นี้ (หากแผนงานของ Eth1.x ได้รับการยอมรับอย่างแพร่หลาย) เราคาดว่าปริมาณงานของ Eth1 จะถูกจำกัดด้วยข้อมูลธุรกรรมมากกว่าพื้นที่จัดเก็บ

หากเราคิดว่าทรูพุตถูกจำกัดด้วยข้อมูลธุรกรรม ดังนั้นเศษบน Serenity จึงไม่จำเป็นต้องเก็บสถานะเพื่อปรับขนาด Ethereum หากทรูพุตถูกจำกัดโดยข้อมูลธุรกรรมจากสัญญาไร้สถานะ ดังนั้น 1,000 ชาร์ดไร้สถานะจะเพิ่มทรูพุตขึ้น 1,000 เท่า

ฟังดูดี แต่จำเป็นต้องดำเนินการผ่านการชาร์ดดิ้ง ซึ่งวางแผนไว้ว่าจะรอจนถึงเฟส 2 ในขณะเดียวกัน เราสามารถใช้ Phase 1 เป็นกลไกจัดการความพร้อมใช้งานของข้อมูลได้ คำว่า data available engine ดูเหมือนจะได้รับความนิยม ลองคิดดูว่ามันทำงานอย่างไร

ยกตัวอย่าง zk-rollup zk-rollup ถูกจำกัดโดยความพร้อมใช้งานของข้อมูล สัญญา zk-rollup บน Eth1 สามารถใช้ Eth2 เป็นผู้ให้บริการรับประกันความพร้อมใช้งานของการเชื่อมโยงได้อย่างมีประสิทธิภาพหรือไม่ หากไม่สามารถรับประกันความพร้อมใช้งานของข้อมูลได้ในระหว่างการดำเนินการ (เช่น การตรวจสอบการพิสูจน์ SNARK และการอัปเดตสถานะรูท) คุณจะลงเอยด้วยระบบ zk-rollback ที่เหมือนพลาสมา แม้ว่าระบบนี้จะช่วยปรับปรุง TPS ได้อย่างมาก แต่ก็จะทำให้เกิดการแลกเปลี่ยนที่ซับซ้อนและจำเป็นต้องจัดการกับความท้าทายของผู้ปฏิบัติงานและกลไกการออกเช่นพลาสมา ในการท้าทายความพร้อมใช้งาน ทุกคนสามารถให้ข้อมูลเพื่อพิสูจน์ความพร้อมใช้งานได้ ดังนั้นจึงไม่ชัดเจนว่าการใส่ข้อมูลลงในชิ้นส่วน Eth2 ที่เชื่อมโยงจะทำให้สิ่งต่างๆ ง่ายขึ้น

ขณะนี้มี zk-rollup เวอร์ชันอื่น 500 TPS zk-rollup ทุกอย่างง่ายขึ้นมาก ไม่จำเป็นต้องมีผู้ดำเนินการที่กำหนดอีกต่อไป ทุกคนสามารถทำหน้าที่เป็นผู้ถ่ายทอดได้ตลอดเวลาและสร้างหลักฐาน SNARK เพื่ออัปเดตสถานะ การรับประกันความพร้อมใช้งานของข้อมูลจะมาพร้อมกับการอัปเดตสถานะเสมอ ซึ่งหมายความว่าไม่จำเป็นต้องจัดการกับความท้าทายของผู้ปฏิบัติงานและกลไกการออกเช่นพลาสมา แต่การดำเนินการนี้ต้องใช้ทั้งการดำเนินการและความพร้อมใช้งานของข้อมูลจึงจะเกิดขึ้นในธุรกรรมเดียวกัน ซึ่งน่าเสียดายที่เราไม่สามารถดำเนินการกับกลไกความพร้อมใช้งานแบบบริดจ์ได้ กล่าวอีกนัยหนึ่ง การเชื่อมโยงเพียงพอสำหรับระบบป้องกันการฉ้อโกง เช่น zk-rollback แต่ไม่เพียงพอสำหรับระบบพิสูจน์ความถูกต้อง เช่น zk-rollup ข้อสรุปคือเพื่อให้การพิสูจน์ความถูกต้องบนเลเยอร์ 2 ง่ายขึ้น ฟังก์ชันสำคัญที่เครื่องมือความพร้อมใช้งานบนเลเยอร์ 1 จำเป็นต้องมีคือเพื่อให้แน่ใจว่าความพร้อมใช้งานของข้อมูลและการดำเนินการเปลี่ยนสถานะเกิดขึ้นพร้อมกันในระดับปรมาณู

บางทีเราไม่ควรแปลกใจกับการรับรู้นี้ หากความพร้อมใช้งานของข้อมูลเพียงอย่างเดียว (โดยไม่มีการดำเนินการ) มีประโยชน์ จะไม่มีใครโต้แย้งว่าเฟส 1 เริ่มต้นขึ้นเพียงเพื่อให้แน่ใจว่ามีความพร้อมใช้งานของ blobs ที่ไม่ใช่ศูนย์จำนวนมาก (วัตถุไบนารีขนาดใหญ่) และไม่มีใครบ่นว่าต้องรอ Eth2 เพื่อ ด่านต่อไปจะเข้ามาเล่นจริงๆ (นอกเหนือจาก PoS) เรากำลังทำงานในเฟส 1 เป็นเครื่องมือความพร้อมใช้งานของข้อมูล แต่ก็ยังไม่ได้ทำอะไรเลย ดังนั้นจึงเป็นเรื่องที่น่าผิดหวัง (ว้าว เราสามารถสร้าง Mastercoin 2.0 ได้!)

เหตุใดเฟส 1 จึงขัดแย้งกับการดำเนินการ สมมติว่ามีการประมวลผลแบบ stateful แต่ละส่วนจะรักษาสถานะในเครื่องไว้ การสับเปลี่ยนตัวตรวจสอบความถูกต้องจะซับซ้อนกว่ามากหากตัวตรวจสอบความถูกต้องจำเป็นต้องรักษาสถานะในเครื่องจำนวนมาก ในทางกลับกัน หากไม่มีการดำเนินการใดๆ ก็ไม่ต้องกังวลเกี่ยวกับรัฐท้องถิ่น การสับเปลี่ยนของ Validator จะง่ายกว่ามาก เราสามารถมุ่งเน้นที่การสร้างชิ้นส่วนข้อมูลด้วย data blobs และเริ่มชิ้นส่วนได้เร็วขึ้น

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

สมมติว่ามีฟิลด์ตัวตรวจสอบใหม่ 3 ฟิลด์ในสถานะของบีคอนเชน: โค้ด stateRoot และ deployedShardId นอกจากนี้ยังมีฟังก์ชั่น process_deploy (ด้านล่าง process_transfer) เมื่อรหัสถูกปรับใช้ ผู้ตรวจสอบจะต้องตรวจสอบให้แน่ใจว่ายอดเงินในบัญชีไม่ต่ำกว่าเกณฑ์ที่กำหนด [อย่างน้อย 1 ETH ถูกล็อค หากไม่มีโปรแกรมทำลายตัวเอง (SELFDESTRUCT) ในโค้ด ส่วนนี้ของ ETH จะเท่ากับถูกทำลาย และโค้ดจะถูกนำไปใช้อย่างถาวร]

ตอนนี้ สมมติว่ามีบางบัญชีที่มีรหัสในสถานะสากลอยู่แล้ว

ต่อไป เราพยายามแพ็ค data blobs เฉพาะลงบนเศษ แต่จะทำอย่างไร เท่าที่ฉันทราบ มันยังคงเป็นคำถามเปิดสำหรับผู้ตรวจสอบความถูกต้องของชิ้นส่วนเฟส 1 เพื่อตัดสินใจว่าจะบรรจุบล็อกข้อมูลใดลงในบล็อกชิ้นส่วน สมมติว่าสิ่งนี้ไม่มีรายละเอียดในข้อกำหนดระยะที่ 1 จากนั้น สำหรับผู้ใช้ หากต้องการแพ็ค data blobs ของตนเองเป็น shards มีเพียงสองวิธีเท่านั้น: (1) ติดต่อผู้ตรวจสอบและส่งไปที่การชำระเงิน (2) เป็นผู้ตรวจสอบด้วยตัวคุณเอง และคุณทำได้ (เมื่อพวกเขา จะถูกสุ่มเลือกให้เป็นผู้เสนอบล็อคของชาร์ด) แพ็ค data blob ลงบนชาร์ด ทั้งสองวิธีนี้เป็นความคิดที่ไม่ดี

วิธีการที่ดีกว่าคือการนำสิ่งต่าง ๆ มาสู่ตารางและอนุญาตให้ผู้ตรวจสอบความถูกต้องจ่ายเงินให้กับผู้เสนอบล็อคปัจจุบันผ่านข้อตกลงการทำธุรกรรม ในการแลกเปลี่ยน ผู้เสนอบล็อคจะบรรจุ data blob ของผู้ตรวจสอบลงใน shard chain อย่างไรก็ตาม วิธีนี้ใช้ไม่ได้หากการดำเนินการบล็อกเชนบีคอน (เช่น การโอนย้ายตัวตรวจสอบความถูกต้อง) มีข้อกำหนดด้านความจุขั้นต่ำ กรณีการใช้งาน "เฟส 1 เป็นเครื่องมือความพร้อมใช้งานข้อมูล" จะไม่สามารถทำได้หากไม่มีโปรโตคอลการทำธุรกรรมที่จะอนุญาตให้ผู้ตรวจสอบความถูกต้องจัดลำดับความสำคัญของการบรรจุข้อมูลหยด (ไม่ว่าจะเป็นสัญญา eth1 ที่เชื่อมต่อผ่านบริดจ์ไปยังบีคอนเชน หรือ Truebit , Mastercoin 2.0, หรือกรณีการใช้งานความพร้อมใช้งานของข้อมูลอื่นๆ ที่ฉันเคยได้ยินมาก่อน) อย่างไรก็ตาม สมมติว่าไม่ว่า Shard offerr จะแพ็ค data blobs ในโหมด "Data Availability Engine without Execution" อย่างไร ก็สามารถอยู่ในโหมด "Data Availability Engine with Simple Stateless Execution" ได้เช่นกัน

เอาล่ะ สมมติว่าบล็อกข้อมูลบางอย่างสามารถบรรจุลงในบล็อกได้ แต่ละบล็อกจะจำกัดการดำเนินการไว้ที่ธุรกรรมเดียว (เช่น ต้องรวม data blob ทั้งหมดเป็นธุรกรรมเดียว) เรายังไม่ได้ชี้แจงว่าการทำธุรกรรมจะลงนามด้วยรหัส (มีข้อตกลงการทำธุรกรรม) หรือไม่จำเป็นต้องลงนาม (ไม่มีข้อตกลงการทำธุรกรรม) สมมติว่าเป็นอย่างหลัง และโค้ดใช้การตรวจสอบลายเซ็นของตัวเอง (คล้ายกับการสรุปบัญชี มีขีดจำกัดของบล็อกแก๊ส แต่ไม่มีกลไกการโอนค่าธรรมเนียม ดังนั้นจึงไม่มีราคาน้ำมันและไม่มีรหัส GASPAY) หากสามารถถอดรหัส Blob เป็นธุรกรรมได้สำเร็จ รหัสบัญชีเป้าหมายจะถูกดำเนินการโดยมีข้อมูลและรูทสถานะปัจจุบันเป็นอินพุต หากดำเนินการสำเร็จ ข้อมูลส่งคืนจะเป็นสถานะรูทใหม่

เราจะอัปเดต stateRoot ของบัญชีตรวจสอบได้อย่างไร เราไม่สามารถอัปเดตรูทสถานะใน BeaconState (สถานะลูกโซ่บีคอน) ของชาร์ดบล็อกแต่ละบล็อกได้ (เนื่องจากจำนวนของการดำเนินการลูกโซ่บีคอนมีจำกัด) อย่างไรก็ตาม ฟิลด์การกระจายตัวในสถานะของบีคอนเชนจะได้รับการอัปเดตด้วยครอสลิงค์ รับสถานะรูทที่อัปเดตของบัญชีทั้งหมดบนชาร์ดเดียวกัน โดยสมมติว่ามีการแฮชเพื่อรับ shard_state_root (รูทสถานะของชาร์ด) shard_state_root ดูเหมือน crosslink_data_root ที่มีอยู่แล้วในการออกแบบเฟส 1 (ทั้งคู่ขึ้นอยู่กับแฮชของเนื้อหาบล็อกชาร์ดก่อนหน้า)

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

แน่นอนว่าไม่มีรายละเอียดมากมายที่นี่ สิ่งที่ฉันพยายามจะสื่อก็คือข้อกำหนดส่วนใหญ่สำหรับการดำเนินการแบบไร้สัญชาติดูเหมือนจะเป็นไปตามขั้นตอนที่ 1 ในความคิดของฉัน ปัญหาที่ใหญ่ที่สุดคือยังไม่ชัดเจนว่าผู้ใช้จะจัดแพ็กเกจ blobs ของพวกเขาบนห่วงโซ่ได้อย่างไร (หากปัญหานี้ไม่ได้รับการแก้ไข เฟส 1 จะไม่สามารถเป็นเครื่องมือในการใช้งานบริดจ์ได้) บางทีนี่อาจเป็นเพียงปัญหาแรกและมีปัญหาร้ายแรงอื่น ๆ ที่ฉันมองข้ามไป ฉันพลาดอะไรไป อะไรคือส่วนที่ยากที่สุดในการอนุญาตให้ผู้ใช้ทำแพ็กเกจ blobs บนเครือข่ายในเฟส 1 (หรือเฟส 1.1 หากคุณต้องการ)