ความคืบหน้า Ethereum เฟส 2 (2019-12)

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

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

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

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

การทำงานกับ Ethereum 2.0 Phase 2 ยังคงดำเนินต่อไป บทความนี้อธิบายถึงการพัฒนาล่าสุดในขณะนี้ งานส่วนใหญ่ในเฟส 2 ดำเนินการโดยความร่วมมือระหว่างทีม Ewasm และทีม Quilt ที่ Ethereum Foundation

เนื้อหาในส่วนต่าง ๆ ของบทความนี้มักจะชี้ไปยังฟิลด์ต่าง ๆ และมีจุดตัดเล็กน้อย ดังนั้น โปรดเลือกส่วนที่คุณต้องการอ่าน ก่อนอ่านบทความนี้ เราขอแนะนำให้คุณทำความเข้าใจความรู้พื้นฐานของ Phase2 และ Execution Environmental Proposal (EE) ก่อนผ่านเนื้อหาต่อไปนี้:

ถนนสู่ Eth 2 Phase 2 และ Testnet Phase 2 (นี่คือการพูดคุยจาก Devcon 5 และสไลด์ที่ใช้สำหรับการพูดคุย)

การตีความเชิงลึกของ EthHub เกี่ยวกับ Ethereum 2.0 Phase 2

เดินทางไปรอบ ๆ Eth2 Phase2 (ความรู้บางจุดล้าสมัย)

Ewasm 2.0: การบังคับใช้ของรัฐใน Eth2.0 (การอ่านขั้นสูง)

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

การเปลี่ยนแปลงเลเยอร์โปรโตคอลที่ส่งผลต่อเฟส 2

ข้อเสนอที่ 2 ของ Vitalik ปรับปรุงข้อเสนอ 1 และแนวคิดใหม่ของ Eth2 ให้เป็นโปรโตคอลไร้สัญชาติ (บล็อกโพสต์นี้มีชื่อหัวข้อว่า "Shard Chains Don't Need State" ซึ่งอธิบายสั้น ๆ ว่าภาวะไร้สัญชาติคืออะไร)

การออกแบบระยะที่ 2 ปัจจุบันไม่ได้เบี่ยงเบนไปจากแนวคิดของข้อเสนอที่ 2 อย่างมีนัยสำคัญ ในอดีต บางส่วนของข้อเสนอเปลี่ยนไปเมื่อมีการแนะนำแนวคิดของการสร้างสมดุลภาระของห่วงโซ่บีคอน แนวคิดเรื่องการจัดสรรภาระงานนี้เสนอให้เข้าใจชาร์ดเชนว่าเป็นกระบวนการประมวลผลแบบบริสุทธิ์ จากนั้น EE จะสามารถทำงานแบบไดนามิกบนชาร์ดเชนที่กำหนดไว้ล่วงหน้าได้ โดยพื้นฐานแล้ว แนวคิดนี้คือการสร้างสมดุลของภาระการประมวลผลให้กับเชนชาร์ดต่างๆ ผ่านสัญญาการสร้างสมดุลภาระงานที่กำหนดไว้ในบีคอนเชน เป็นสิ่งที่ควรค่าแก่การเน้นย้ำว่าแนวคิดการออกแบบนี้น่าสนใจมาก และโหมดต่างๆ ของธุรกรรมซิงโครนัสข้ามชาร์ดสามารถรับรู้ได้ผ่านรีเลย์ที่ทำงานร่วมกัน มันสมควรได้รับความพยายามมากกว่านี้สำหรับการวิจัยของเรา หากเชื่อถือได้ เราจะเพิ่มเครื่องมือนี้ใน shard chain ในอนาคต (อาจจะหลังจากที่ออนไลน์แล้ว)

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

Scout

เรามีความคืบหน้าอย่างมากในการสร้างต้นแบบและการใช้งานสภาพแวดล้อมการดำเนินการในช่วงต้น ขั้นแรก เราต้องตรวจสอบว่าสภาพแวดล้อมการดำเนินการสามารถทำงานในโหมดไร้สถานะได้ จำนวนข้อมูลหลักฐาน/พยานที่จำเป็นสำหรับสภาพแวดล้อมการดำเนินการนี้จะมากเกินไปหรือไม่ การใช้การพิสูจน์เพื่อดำเนินการเปลี่ยนสถานะใช้เวลานานเกินไปหรือไม่ เพื่อตอบคำถามเหล่านี้เราได้สร้างสภาพแวดล้อมการดำเนินการจำนวนมากและใช้สภาพแวดล้อมเหล่านี้เพื่อศึกษาคำถามเหล่านี้ อย่างไรก็ตาม อันดับแรกเราต้องการเครื่องมือสำหรับสร้างต้นแบบ: Scout

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

Scout เป็นเครื่องมือสร้างต้นแบบกระบวนการดำเนินการ Ethereum 2.0 เฟส 2 (เดิมพัฒนาโดย Alex Beregszaszi) ซึ่งได้พัฒนา wrapper สำหรับ Ewasm API ดังนั้นนักพัฒนาสามารถใช้เพื่อสร้างต้นแบบของสภาพแวดล้อมการดำเนินการและทำการทดสอบเกณฑ์มาตรฐาน ( การเปรียบเทียบ) และยังมีสคริปต์การประกอบและพอร์ต C ++

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

EE ที่เกี่ยวข้องกับ Eth1

เพื่อรองรับการเปลี่ยนจาก Eth1 เป็น Eth2 เราจำเป็นต้องสร้างกฎการเปลี่ยนสถานะของ Eth1 ให้เป็นสภาพแวดล้อมการดำเนินการใน Eth2 ความท้าทายหลักของสวิตช์นี้คือการแปลง Eth1 เป็นโมเดลไร้สถานะ จากนั้นแปลง EVM และโมเดลธุรกรรม/บัญชีเป็นสภาพแวดล้อมการดำเนินการ EEs ที่กล่าวถึงด้านล่างเป็นรุ่นก่อนหน้าของ Eth1 EE เมื่อเร็ว ๆ นี้ได้มีการจัดตั้งคณะทำงานเพื่อมุ่งเน้นการพัฒนา Eth1 EE อย่างมาก พวกเขาวางแผนการทำงานเบื้องต้นและแนะนำตัวเองในฟอรัมการวิจัยจริยธรรม

โทเค็น Merkel Patricia Tree (SMPT) ไร้สัญชาติ

แหล่งที่มาหลัก: Github การนำเสนอของ Sina Mahmoodi ที่ Devcon 5

ต้นแบบแรกของโทเค็นไร้สัญชาติ EE มีเป้าหมายเพื่อเลียนแบบสถาปัตยกรรมของ Eth 1.0 ใช้รหัสฐานของพาริตีเพื่อใช้แผนผังสถานะ Eth1 (Hexary Merkle-Patricia Trie) และกฎการเข้ารหัส RLP นอกจากนี้ยังรวมการใช้งานรีเลย์พื้นฐานที่ช่วยให้รีเลย์สร้างหลักฐานหลายรายการสำหรับชุดธุรกรรม

เกณฑ์มาตรฐาน: ธุรกรรม 70 รายการและ 5,000 บัญชี/ลีฟโหนด

Turbo Token

เวลาที่ใช้: 5 วินาที

ขนาดหลักฐาน : 235 kb

การปรับปรุงที่สำคัญยังจำเป็นในการดำเนินการดำเนินการและขนาดของหลักฐาน แต่ความคืบหน้าก็เห็นได้ชัดจากผลลัพธ์ในช่วงแรกนี้ ปัญหาหนึ่งเกี่ยวข้องกับการคอมไพล์ไลบรารี่สนิมของ Parity เป็นโค้ด wasm ซึ่งส่งผลให้เกิดการดำเนินการ memcopy (สำเนาหน่วยความจำ) และความไร้ประสิทธิภาพอื่นๆ โดยทั่วไป การรวบรวมสนิมเพื่อประกอบเว็บได้พิสูจน์แล้วว่าค่อนข้างยาก นอกจากนี้ รายการตรวจสอบลายเซ็นใช้เวลา 4 วินาที (จากทั้งหมด 5 วินาที)

ข้อมูลหลัก: ภาพรวม Turboproof (หมายเหตุบรรณาธิการ: ดูไฮเปอร์ลิงก์ที่ท้ายบทความสำหรับการแปลภาษาจีน), Turboproof Rust Github, Turbo Token Github, สุนทรพจน์ Devcon 5 ของ Guillaume Ballet, สุนทรพจน์ Devcon 5 ของ Sina Mahmoodi

เทคโนโลยี turboproofs ที่ใช้ในโมเดล Turbo Token ได้รับการวิจัยเบื้องต้นโดย Alexey Akhunov เพื่อใช้ไคลเอนต์แสงไร้สถานะ Eth1 มันสามารถสร้าง ผสาน และจัดลำดับ multiproof ของแผนผังข้อมูล Eth1 ได้อย่างมีประสิทธิภาพและยังรองรับการทำงานแบบเดี่ยว (single pass) ได้อย่างมีประสิทธิภาพ อัปเดตแผนผังข้อมูล Casey Detrio และ Sina พัฒนาต้นแบบสาขาเดียวเริ่มต้นในสคริปต์การประกอบและสนิมเพื่อตรวจสอบว่าการป้องกันเทอร์โบมีประสิทธิภาพเพียงพอ หลังจากเริ่มได้รับผลลัพธ์ที่น่าพอใจในต้นแบบสาขาเดียว Casey ได้นำโทเค็น EE ที่มีการพิสูจน์เทอร์โบที่เรียบง่ายและใช้งานได้โดยทั่วไปมาใช้กับสคริปต์การประกอบ Sina Mahmoodi คัดลอกการใช้งานนี้แล้วย้ายฐานโค้ดเบสและตัวสร้างสนิมแบบป้องกันเทอร์โบของ Guillaume ไปเป็น typescript

เกณฑ์มาตรฐาน: ธุรกรรม 70 รายการและ 5,000 บัญชี/ลีฟโหนด

เวลาที่ผ่านไป: 140 ms

ขนาดหลักฐาน 50 kb

ล่าม EVM EE

สรุป

เราจำเป็นต้องพัฒนาตัวแปล EVM (มีเว็บแอสเซมบลี) ในเครื่องมือดำเนินการเพื่อรองรับ Eth1 EE Hugo สร้างต้นแบบและทดสอบรอบสัญญาเพิ่มเติมและ mul256 ในอนาคต ต้องมีการแนะนำสัญญาและเกณฑ์มาตรฐานเพิ่มเติมเพื่อปรับปรุงต้นแบบนี้

สรุป

งานทดลองทั้งหมดที่กล่าวถึงข้างต้นคือการปรับใช้สภาพแวดล้อมการดำเนินการ Eth1 เราได้เริ่มสร้างต้นแบบแล้ว แต่ยังมีปัญหาด้านประสิทธิภาพอีกมากที่ต้องพิจารณา ตามที่กล่าวไว้ข้างต้น คณะทำงานเพิ่งเริ่มให้ความสนใจกับการพัฒนา Eth1 EE และสร้างแบบจำลองไร้สถานะ Eth1

C Merkle Token

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

EEs มีศูนย์กลางอยู่ที่ Eth2

ส่วนนี้จะแนะนำ EE ที่ไม่ได้รับการพัฒนาอย่างสมบูรณ์สำหรับการย้ายข้อมูล Eth1 -> Eth2 Eth2 จะใช้สภาพแวดล้อมการดำเนินการตามบัญชีแบบใหม่ ซึ่งแตกต่างจากรูปแบบบัญชีและธุรกรรมของ Eth1 เนื่องจากรูปแบบการทำธุรกรรม บัญชี และตัวสะสมที่ใช้โดย Eth1 นั้นไม่เหมาะสม นอกจากนี้ ควรศึกษาแบบจำลองต่างๆ เช่น optistic rollups และ ZK rollups พื้นที่การออกแบบสำหรับ Eth2 EE นั้นเปิดกว้าง และต่อไปนี้เป็นแนวคิดและต้นแบบเบื้องต้น

ข้อมูลหลัก: Github, การนำเสนอ Devcon 5

การใช้ C ของ Paul Dworzanski ของโทเค็น Merkle ไร้สัญชาติโดยใช้ต้นไม้ Merkle แบบไบนารี (แทนที่จะเป็นต้นไม้ Merkle ที่กระจัดกระจาย) การตรวจสอบและอัปเดตแผนผังข้อมูลใช้การกระจายหน่วยความจำที่เหมาะสมที่สุด และจัดรูปแบบมัลติปรู๊ฟที่ไม่เหมือนใคร การดำเนินการตรวจสอบและอัปเดตแผนผังข้อมูลของโมเดลนี้เสร็จสมบูรณ์ในหนึ่งรอบ (รอบเดียว) (ดังนั้นจึงหลีกเลี่ยงการดำเนินการคัดลอกหน่วยความจำ (memcopy และการทำสำเนา)) และมีความเป็นไปได้สูงที่จะสามารถใช้กับโครงสร้างข้อมูลเลขฐานสิบหกของ Eth1 ได้ อย่างไรก็ตาม ยังไม่ชัดเจนว่าอัลกอริทึมการอัปเดตแผนผังข้อมูลสามารถใช้กับแผนผังข้อมูล Eth1 ได้หรือไม่ (เนื่องจากโดยทั่วไปแล้วโมเดลที่ใช้ Eth1 จะใช้การส่งผ่านหลายครั้ง)

เกณฑ์มาตรฐาน: 40 จาก 222 บัญชีที่เกี่ยวข้องกับการพิสูจน์

ZK Rollup

เวลาที่ผ่านไป: 20 ms (ไม่รวมการตรวจสอบลายเซ็น)

ขนาดหลักฐาน : 25 kb

Shard Ether (Sheth)

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

ข้อมูลหลัก: ภาพรวม ZK Rollup ทั่วไป (หมายเหตุบรรณาธิการ: สำหรับการแปลภาษาจีน ดูไฮเปอร์ลิงก์ "ZK rolup vs. Optimistic rollup" ที่ท้ายบทความ), คำพูดของ Devcon 5, ตัวอย่างการตรวจสอบ EE โดยสิ้นเชิง, ตัวตรวจสอบหลักฐาน WASM, snarks เว็บ

ZK rollups เป็นโซลูชันส่วนขยาย Layer-2 เนื่องจากไม่ได้ใช้กลไกการท้าทายทางออกที่ซับซ้อนและกลไกการล็อคจึงสามารถหลีกเลี่ยงปัญหาประสบการณ์ผู้ใช้ทั่วไปในโซลูชัน Layer-2 ที่มีอยู่ เมื่อเปรียบเทียบกับแผนการถ่ายโอนโทเค็นอื่นๆ ที่แสดงรายการไว้ที่นี่ ZK Rollup จะปรับลดข้อกำหนดด้านความพร้อมใช้งานของข้อมูลลงอย่างมาก การใช้งานที่แสดงรายการที่นี่ใช้เว็บ snark - ตัวสร้างที่ใช้งานใน wasm ที่สามารถใช้สำหรับการตรวจสอบ snark หรือฟังก์ชันการจับคู่อื่นๆ ในการพัฒนา EE จาเร็ดดัดแปลง websnark โดยพัฒนาไลบรารี wasm แยกต่างหากสำหรับตรวจสอบการพิสูจน์ของ Groth16 EE นี้ยังเป็นต้นแบบระยะแรกและต้องพัฒนาต่อไป

แหล่งที่มาหลัก: Github, การพูดคุย Devcon 5 ของ Matt Garnett, การพูดคุยภายใน Quilt (รายละเอียดเพิ่มเติม), ภาพรวม SSZ

Sheth เป็นสารตั้งต้นของสัญญา Eth2 EE (ขึ้นอยู่กับ Eth1 แต่ทำซ้ำเพื่อให้เหมาะกับ wasm / Eth2) Sheth ขึ้นอยู่กับ Simple Serialization Encoding Specification (SSZ) ที่ใช้ใน Eth2 ซึ่งใช้แผนผัง Merkle tree แบบกระจาย ยืม opcodes แบบ turboproof แต่ใช้รูปแบบอื่นเพื่อจัดการข้อกำหนดการอ่าน เขียน และอัปเดต แนวคิดการออกแบบของ Diederik Loerakker คือการตัดสินใจว่าจะสำรวจแผนผังข้อมูลทั้งหมดอย่างไรโดยจัดเก็บรายการออฟเซ็ต จุดแข็งของการพิสูจน์ Merkle tree แบบกระจัดกระจายคือคุณสามารถกำหนดดัชนีโดยรวมของข้อมูลที่คุณกำลังอ้างอิงในเวลาคอมไพล์ได้แบบคงที่ นอกจากนี้ยังช่วยลดความซับซ้อนของตรรกะที่จำเป็นในการอัปเดตสถานะ เนื่องจากโหนดจะไม่ถูกลบหรือแทรกลงในแผนผังข้อมูล อย่างไรก็ตาม มีการเสียสละบางอย่าง (การคำนวณแฮชความเข้มสูง) สำหรับสิ่งนี้ Sheth ยังมีไคลเอนต์บรรทัดคำสั่งที่สามารถทำหน้าที่เป็นผู้ส่งต่อหรือผู้ให้บริการสถานะ

เกณฑ์มาตรฐาน: 50 บัญชีและ 50 ธุรกรรม

ขนาดหลักฐาน : 517 kb

SimpleUmbrella — Eth2 สัญญาอัจฉริยะ EE

เนื้อหาหลัก: ข้อเสนอในฟอรัม Eth Research, รันโค้ดโฮสต์ฟังก์ชัน PR

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

Ewasm - ล่าม คอมไพเลอร์ และเมตริกการคำนวณ

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

นักแปล

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

ล่าม

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

เมตริกการคำนวณ

Paul Dworzanski สำรวจพื้นที่นี้ในเชิงลึกในการพูดคุยเรื่อง Devcon 5 ของเขา ในการวัดการคำนวณ การเรียก use_gas จะใส่รหัส wasm bytecode (ไม่ว่าจะทำงานใน EE หรือ EE ร่ม) เมื่อสัญญา wasm ถูกปรับใช้และตรวจสอบ ความซับซ้อนของการฉีดและการยืนยันจะส่งผลต่อต้นทุนของการปรับใช้สัญญาอย่างไม่ต้องสงสัย เกณฑ์มาตรฐานปัจจุบันแสดงให้เห็นว่าโค้ด wasm ทำงานช้าลง 1.04-2.4 เท่าหลังจากใส่เมตริกการคำนวณ การเปรียบเทียบรูปแบบที่ดีขึ้นของกระบวนการฉีดและการประกอบรีจิสทรีจะชี้ให้เห็นถึงการเพิ่มประสิทธิภาพเพิ่มเติม

ต้นแบบเฟส 1 และ 2 ในไคลเอนต์ Lighthouse หรือการจำลองเฟส 2

เราต้องการจำลองว่าไคลเอนต์เฟส 1 และ 2 จะถูกสร้างขึ้นอย่างไร และทีมที่พัฒนาการใช้งานจะได้รับการสนับสนุนอย่างไร นอกจากนี้ เรายังหวังว่าจะใช้งานนี้เพื่อจำลองและทดสอบ EE ที่ทำงานบนชาร์ดต่างๆ ในสภาพแวดล้อมจริง ในช่วง Devcon 5 ฉันได้พูดคุยเกี่ยวกับการจำลองที่เราสร้างขึ้น เราพัฒนา/แนะนำต้นแบบเฟส 1 ที่เรียบง่ายมาก (ไม่มีการเพิ่มส่วนประกอบเครือข่าย) ในไคลเอนต์ Lighthouse และรวมรันไทม์ Ewasm เฟส 2 ไว้ในไคลเอนต์ เราโต้ตอบกับ Sheth (Sheth ทำหน้าที่เป็นผู้ส่งต่อและผู้ให้บริการของรัฐ) และสามารถจำลองการถ่ายโอน EE หรือโทเค็นพื้นฐานใน Lighthouse

เนื่องจากไคลเอนต์ Lighthouse ยังคงได้รับการพัฒนาอย่างต่อเนื่อง เราจึงตระหนักว่าการรักษาไคลเอนต์ Lighthouse ไว้และพัฒนาต่อยอดนั้นน่าจะยากกว่าที่เราคิดไว้ในตอนแรก ดังนั้นเราจึงตัดสินใจนำสารอาหารจากต้นแบบเริ่มต้นมาพัฒนาเป็นเวอร์ชันนามธรรมภายใน Scout เราจะจำลองการทำงานของ beacon chain และ shard chain ต่อไป แต่เราสามารถลดความซับซ้อนของตรรกะได้อย่างมาก เนื่องจากเรามุ่งเน้นที่การวิจัยสภาพแวดล้อมการดำเนินการและการเปรียบเทียบข้ามชาร์ด งานส่วนนี้ได้รับการจัดการโดยสมาชิกใหม่สองคนของทีม Quilt

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

John Adler ได้เขียนภาพรวมที่ครอบคลุมมากเกี่ยวกับหัวข้อนี้ บทความของเขายังบอกเล่าวิวัฒนาการที่น่าสนใจของข้อเสนอ Eth2 โดยสรุป ข้อเสนอลดความซับซ้อนของการแบ่งส่วนย่อยล่าสุดของ Vitalik ช่วยขจัดปัญหามากมายที่เรามีกับโมเดลรีเลย์ตั้งแต่แรก อย่างไรก็ตาม ยังมีคำถามเปิดอยู่มากมายเกี่ยวกับวิธีที่ผู้ให้บริการของรัฐส่งธุรกรรมไปยังผู้ผลิตบล็อก และวิธีที่ผู้ผลิตบล็อกรวมชุดธุรกรรมเข้ากับมัลติปรู๊ฟที่เหมาะสม หนึ่งในข้อเสนอคือการปรับใช้สภาพแวดล้อมการดำเนินการใหม่ด้วยสคริปต์ผสานการพิสูจน์

ในที่สุด ผู้ส่งต่อหรือผู้ให้บริการสถานะจะรับตำแหน่งข้อมูล RPC ที่ web3.js หรือ ethers.js เชื่อมต่ออยู่ เป็นสิ่งสำคัญที่จะต้องกำหนดมาตรฐานสำหรับการดำเนินการเหล่านี้ใน EE หลายแห่ง

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

ธุรกรรมข้ามชาร์ด

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

• ธุรกรรมข้ามส่วนแบบอะซิงโครนัส

• ข้อเสนอ Phase 0 & 1 ล่าสุดของ Vitalik เป็นข่าวดีสำหรับทั้งธุรกรรมข้ามชาร์ดและความสามารถในการจัดองค์ประกอบ ในข้อเสนอใหม่ การโทรข้ามชาร์ดสามารถดำเนินการให้เสร็จสิ้นได้ด้วยการหน่วงเวลาเพียงหนึ่งช่วงเวลา (6 วินาที) ในขณะที่ข้อเสนอที่ผ่านมา การโทรต้องรอการหน่วงเวลา 12 ถึง 18 นาทีจึงจะสิ้นสุด ดังนั้น การถ่ายโอนสถานะของคุณ (หรือ eth) ระหว่างเศษชิ้นส่วนจึงรวดเร็วมาก ก่อนหน้านี้ เราต้องการใช้รากที่มองโลกในแง่ดีเพื่อเร่งการโทร แต่พบว่าวิธีแก้ปัญหาเหล่านี้ซับซ้อนมาก

• จากมุมมองของนักพัฒนา dApp การเรียกใช้ข้ามชาร์ดจำเป็นต้องทำตามกระบวนทัศน์และวิธีการแบบอะซิงโครนัสเท่านั้นในการเขียนโปรแกรมแบบมัลติเธรด เมื่อเขียนสัญญาอัจฉริยะ HLL (Slodity) และ DSL (Vyper) จำเป็นต้องมีเครื่องมือที่จำเป็นเพื่อแยกพฤติกรรมข้ามชาร์ดออกเป็นกระบวนทัศน์แบบอะซิงโครนัส สคีมาทั้งหมดจะมีลักษณะดังนี้:

• การโทรแบบอะซิงโครนัสอย่างง่าย (รอ async, การโทรกลับ ฯลฯ)

การยืนยันแบบสองเฟส (atomicity)

ล็อค - อ่าน/เขียน (ดึงสัญญา)

วิธีสนับสนุนรูปแบบเหล่านี้ใน EE หรือในสัญญาอ้างอิงจำเป็นต้องมีการวิจัยเพิ่มเติม การจำลองที่กล่าวถึงข้างต้น (และเครื่องมือประสานที่กล่าวถึงด้านล่าง) ควรเป็นพื้นฐานสำหรับการทดลองของเรากับแบบจำลองเหล่านี้ แต่จริงๆ แล้ว เราจะบอกว่านี่เป็นส่วนสำคัญของการวิจัย และหากผู้คนเต็มใจที่จะมีส่วนร่วม เราจะ มีความสุขมากๆ การระบุพฤติกรรมก่อนกระบวนการและหลังกระบวนการในระดับที่ต่ำกว่า ตามที่อธิบายไว้ในโพสต์นี้ อาจให้กรอบการทำงานที่สมเหตุสมผลสำหรับการระงับและการดำเนินการต่อภายในสัญญาในภายหลัง

ซิงโครไนซ์ธุรกรรมข้ามชาร์ด

ก่อนหน้านี้ Vitalik ได้เผยแพร่โพสต์เกี่ยวกับแผนการของรัฐ สาระสำคัญของโซลูชันเหล่านี้คือโหมดเลเยอร์ 2 บนเชน และการแยกส่วนจะใช้เป็นเลเยอร์ความพร้อมใช้งานของข้อมูลเท่านั้น แบบจำลองเหล่านี้ (นั่นคือ แบบจำลอง "การประมวลผลสถานะล่าช้า" ในตำนานก่อนหน้านี้ แบบจำลอง "การดำเนินการแบบขี้เกียจ" หรือ "ห่วงโซ่เงา") แท้จริงแล้วเป็นรุ่นก่อนหน้าของสิ่งที่เรียกว่าการยกเลิกในแง่ดี การใช้ชาร์ดหลายรายการเป็นชั้นความพร้อมใช้งานของข้อมูลสำหรับแผนการยกเลิกในแง่ดีทำให้สามารถซิงโครไนซ์ธุรกรรมข้ามชาร์ดได้ เราอาจพัฒนาต้นแบบตามแนวคิดนี้ในอนาคตอันใกล้นี้

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

เราจำเป็นต้องโทรข้ามเศษหรือไม่?

อีกมุมมองที่ควรค่าแก่การศึกษาเพิ่มเติมคือเนื้อหาหลักของ Eth2 ควรเอนเอียงไปทางช่องทางของรัฐ การเลิกใช้ในแง่ดี และการเลิกใช้ zk (หลังจากที่แผนการเหล่านี้บรรลุนิติภาวะแล้ว) ในแนวคิดนี้ Eth2 เองเป็นเลเยอร์ความพร้อมใช้งานของข้อมูล และการเรียกใช้ข้ามชาร์ดจะใช้เฉพาะเมื่อเชื่อมโยงโครงร่างเหล่านี้หรือระหว่างการท้าทายทางออก/การพิสูจน์เท็จ ยังคงต้องกำหนดค่าสะสมภายในขอบเขตของสภาพแวดล้อมการดำเนินการ Eth1 หรือ Eth2 อย่างไรก็ตาม การคำนวณจะต้องดำเนินการแบบออนไลน์เท่านั้นเมื่อจำเป็นต้องส่งการพิสูจน์ข้อผิดพลาด

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

• ระยะที่ 2 ห่วงโซ่เครื่องมือ

• เพื่อพัฒนาการวิจัยของเรา เราเสนอ toolchain ที่นักพัฒนาจำเป็นต้องใช้ ตามที่กล่าวไว้ในหัวข้อ "ต้นแบบระยะที่ 1 และระยะที่ 2 ในประภาคาร" ข้างต้น เรากำลังพัฒนาชุดของการจำลองเพื่อทดสอบและเรียกใช้สภาพแวดล้อมการดำเนินการทั่วทั้งชาร์ด อย่างไรก็ตาม เพื่อเพิ่มประสิทธิภาพโหมดการทำงานของสัญญาอัจฉริยะ เราต้องเพิ่มเครื่องมือการประสานจำนวนมาก โพสต์นี้จะอธิบายเครื่องมือเหล่านี้ในเชิงลึกยิ่งขึ้น

• การจำลองเฟส 1 และ 2

• แทรกสภาพแวดล้อมรันไทม์ของไคลเอนต์ Phase 1

แบ็คเอนด์แบบหลายตัวที่เชื่อถือได้ (อนุญาตให้ลูกค้าสร้าง รวม และจัดการหลายตัว)

Relayer เครื่องมือของผู้ให้บริการของรัฐสำหรับการโต้ตอบกับ web3.js (ดูส่วน "รีเลย์ ผู้ให้บริการของรัฐ และตลาดค่าธรรมเนียม")

• Eth1 ->ชื่อระดับแรก

• ผลงานอื่น ๆ ของ Vitalik ใน Phase2

• Vitalik ยังได้กล่าวถึงหัวข้อที่เกี่ยวข้องกับเฟส 2 ในโพสต์อื่นๆ เมื่อเร็ว ๆ นี้ แต่ฉันไม่ได้อ้างถึงโดยตรงข้างต้น ในที่นี้ขอชี้ให้เห็นว่า:

• การโยกย้าย Eth2

• ตระหนักถึงธุรกรรมข้ามชาร์ด

• ทำให้เป็นทางการและปรับปรุงแนวทางของ Eth2 เพื่อกำหนดการตอบสนองต่อ Shard Blocks ที่ไม่ถูกต้อง

สัญญาที่บันทึกไว้ในห่วงโซ่สัญญาณ

ความสามารถในการผสม DeFi แบบข้ามชาร์ด

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

สรุปแล้ว

ในที่สุด เราจะเริ่มการประชุมวิดีโอรายเดือนของเรา การประชุมครั้งแรกกำหนดไว้ในวันอังคารที่ 3 ธันวาคม เวลา 10:00 น. ET

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