ความคิดเห็น: แผนงานของ Ethereum ควรเปลี่ยนแปลงหรือไม่

หมายเหตุบรรณาธิการ: บทความนี้มาจากผู้ที่ชื่นชอบ Ethereum (ID: ethfans)ผู้แต่ง: A Jian ทำซ้ำโดย Odaily โดยได้รับอนุญาต

ผู้ที่ชื่นชอบ Ethereum (ID: ethfans)แปลภาษาจีนผู้ที่ชื่นชอบ Ethereum (ID: ethfans)

ผู้แต่ง: A Jian ทำซ้ำโดย Odaily โดยได้รับอนุญาตจาก "แผนงาน ethereum ที่เน้นการรวมศูนย์" (แปลภาษาจีน

) นับตั้งแต่มีการเผยแพร่บทความ ชุมชนทั้งหมดได้ตั้งคำถามเกี่ยวกับแผนงานของ Ethereum (โดยเฉพาะ Ethereum 2.0)

แปลจีนของข้อความที่ตัดตอนมา

) Vitalik ระบุอย่างชัดเจนว่าแผนงานมีการเปลี่ยนแปลง: (1) ความสำคัญของเฟส 2 ไม่ได้เน้นย้ำในขณะนี้อีกต่อไป และเฟส 1 ทุ่มเทให้กับการนำ data sharding (shard data) มาใช้สำหรับการใช้งานแบบโรลอัพ (2) Beacon เชนจะมีฟังก์ชันการดำเนินการ นั่นคือ หลังจากการควบรวมกิจการของ Eth1-Eth2 บล็อกเชนบีคอนจะมีธุรกรรมโดยตรง (3) ภารกิจหลักสามประการหลังจากดำเนินการเฟส 0: การสนับสนุนไคลเอ็นต์แบบเบา การกระจายตัวของข้อมูล และ การควบรวมกิจการจะได้รับการเลื่อนขั้นไปพร้อม ๆ กัน โมดูลใดโมดูลหนึ่งจะเปิดตัวทันทีที่พร้อม

แผนงานสามขั้นตอนสำหรับ Eth2.0

• เฟส 0: Beacon chain พร้อม PoS เป็นกลไกฉันทามติ

• ระยะที่ 1: เชนย่อยหลายรายการ

• ขั้นที่ 2: เพิ่มฟังก์ชันการดำเนินการให้กับชาร์ดทั้งหมด

ในช่วงสองปีที่ผ่านมา แผนงาน Eth2.0 ที่มีการเผยแพร่อย่างกว้างขวางได้วางแผนองค์ประกอบตามลำดับสามส่วน:

เฟส 0: Beacon chain พร้อม PoS เป็นกลไกฉันทามติ

ระยะที่ 1: เชนย่อยหลายรายการ

ขั้นที่ 2: เพิ่มฟังก์ชันการดำเนินการให้กับชาร์ดทั้งหมด

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

สถาปัตยกรรม "PoS beacon chain + multi-shard" นี้ดูเหมือนว่าจะใช้ประโยชน์จากคุณลักษณะของอัลกอริทึม PoS ได้ดี: เพื่อแก้ปัญหาที่ไม่มีสิ่งที่เป็นเดิมพัน (บล็อก PoS ไม่จำเป็นต้องจ่ายค่าคำนวณ ดังนั้น พวกเขามีสิทธิ์บัญชีที่ผลิตบล็อกจะพยายามสร้างบล็อกบนส้อมที่แตกต่างกันในเวลาเดียวกันทำให้ระบบพัง) อัลกอริทึมของ Casper ที่ใช้ใน Ethereum 2.0 กำหนดให้ผู้ใช้ต้องฝากเงินส่วนหนึ่งก่อนจึงจะมีสิทธิ์ สำหรับการผลิตบล็อกและหากผู้ตรวจสอบใช้คุณสมบัติการผลิตบล็อกในทางที่ผิด (เช่น รองรับสองส้อมในเวลาเดียวกัน) เงินมัดจำจะถูกปรับ ดังนั้น อัลกอริทึมอย่างแคสเปอร์จึงสร้างสถานะสองสถานะบนบล็อกเชนที่สามารถสื่อสารระหว่างกันได้ เปลี่ยนแปลงโดยอิสระจากกัน: สถานะหนึ่งเป็นเรื่องปกติ อีกสถานะหนึ่งคือสถานะของผู้ใช้ และอีกสถานะหนึ่งคือสถานะน้ำหนักบล็อกของผู้ตรวจสอบ กระบวนการฉันทามติจะขึ้นอยู่กับสถานะน้ำหนักบล็อก และการได้รับฉันทามติก็จะเปลี่ยนบล็อกด้วย สถานะน้ำหนัก ดังนั้น กระบวนการฉันทามติโดยเนื้อแท้แล้วเป็นอิสระจากการตรวจสอบธุรกรรมของผู้ใช้ ซึ่งสามารถแก้ปัญหาการมีเพศสัมพันธ์ได้ สำหรับแบทช์ธุรกรรมตามอำเภอใจและสถานะผลลัพธ์ กระบวนการฉันทามติสามารถสรุปเป็น "กลไกการสรุปขั้นสุดท้าย" และในเชิงตรรกะแล้ว การดำเนินการแบบขนานของชาร์ดเป็นไปได้

สำหรับความสามารถในการปรับขนาดนั้น ชื่อของเทคโนโลยี Ethereum sharding "Quadratic sharding (Quadratic sharding)" เผยให้เห็นเงื่อนงำ: สมมติว่าความซับซ้อนในการดำเนินการของธุรกรรมบน shard สามารถลดลงให้มีความยากเท่ากับการตรวจสอบส่วนหัวของบล็อก จากนั้นสถาปัตยกรรมการดำเนินการแบบแยกส่วนสามารถทำให้ความสามารถในการประมวลผลของทั้งระบบเพิ่มขึ้นเป็นกำลังสองเนื่องจากความสามารถในการประมวลผลของโหนดที่เข้าร่วมเพิ่มขึ้นแบบเชิงเส้น ในแง่ของคนธรรมดา หากโหนดที่เข้าร่วมในเครือข่าย (โดยเฉลี่ย) สามารถตรวจสอบส่วนหัวของบล็อกได้ 4 รายการภายในระยะเวลาหนึ่ง หมายความว่าเมื่อเข้าร่วมในชาร์ด โหนดจะสามารถตรวจสอบธุรกรรมได้ 4 รายการในเวลาเดียวกัน ความสามารถในการประมวลผลทั้งหมดของ ระบบคือ 4 ชาร์ด × 4 ธุรกรรม/ชาร์ด = 16 ธุรกรรม หากความสามารถในการประมวลผลของโหนดกลายเป็น 8 (2 เท่า) ความสามารถในการประมวลผลจะกลายเป็น 64 ธุรกรรม (4 เท่า)

ฟังดูดี แต่อาร์กิวเมนต์ "การขยายระดับสี่เหลี่ยม" รวมถึงสมมติฐานต่อไปนี้:

(1) มีเทคโนโลยีที่ทำให้การตรวจสอบธุรกรรมเศษส่วนง่ายขึ้นให้มีความยากเท่ากับการตรวจสอบส่วนหัวของบล็อก

(2) ไม่มีธุรกรรมข้ามชาร์ด กล่าวคือ ธุรกรรมในแต่ละชาร์ดจะไม่ขึ้นต่อกันเลย ธุรกรรมข้ามชาร์ดจำเป็นต้องใช้ความสามารถในการประมวลผลของชาร์ดหลายตัว และยังใช้ความสามารถในการประมวลผลของบีคอนเชน ซึ่งจะช่วยลดความสามารถในการปรับขนาดได้อย่างมาก

เกี่ยวกับข้อ (1) ข้อสันนิษฐานนี้น่าจะเป็นที่พอใจ การไร้รัฐไร้สัญชาติเป็นเทคโนโลยีดังกล่าว แนวคิดของมันคือเมื่อเผยแพร่ธุรกรรม (หรือบล็อกการเผยแพร่) มีหลักฐานสถานะการเข้าถึงของการแลกเปลี่ยน (พยาน) เพื่อให้ ผู้ตรวจสอบธุรกรรมสามารถตรวจสอบความถูกต้องของธุรกรรมโดยไม่ต้องเก็บข้อมูลสถานะ ณ เวลาที่ดำเนินการธุรกรรม สิ่งนี้สำคัญมาก หากไม่มีสถานะไร้สัญชาติ ผู้ตรวจสอบที่เข้าร่วมในการตรวจสอบ Shard ต้องบันทึกสถานะของ Shard เนื่องจากผู้ตรวจสอบจะถูกกำหนดให้กับ Shard Chain ต่างๆ อย่างต่อเนื่อง ซึ่งหมายความว่าจะต้องบันทึก Shard ทั้งหมด ในทางปฏิบัติ หมายความว่าพวกเขาต้องดาวน์โหลดบล็อกของชาร์ดทั้งหมดอย่างต่อเนื่องและประมวลผลธุรกรรม เพื่อให้ทั้งระบบยุบรวมเป็นระบบบล็อกขนาดใหญ่ (ตัวอย่างเช่น: ลงทุนทรัพยากรที่สามารถประมวลผล 16 ธุรกรรม ประมวลผล 16 ธุรกรรม) น่าเสียดายที่จนถึงตอนนี้ Ethereum 1.0 ยังไม่ได้พัฒนาวิธีไร้สัญชาติที่มีน้ำหนักเบาเพียงพอ

นอกเหนือจากความสามารถในการปรับขนาดที่น่าสงสัยแล้ว การดำเนินการแบบแยกส่วนยังก่อให้เกิดปัญหาที่น่าสนใจทางเศรษฐกิจอีกหลายประการ ตัวอย่างเช่น หากเวลาในการประมวลผลของธุรกรรมข้ามชาร์ดเกินเวลาการประมวลผลของธุรกรรมภายในชาร์ด (ซึ่งเป็นสิ่งที่หลีกเลี่ยงไม่ได้) หมายความว่ามูลค่าของ ETH ในชาร์ดต่างๆ จะไม่เท่ากัน ราวกับว่าเงินดอลลาร์ในสหรัฐอเมริกาไม่เหมือนกับเงินดอลลาร์นอกสหรัฐอเมริกา ไม่ว่าจะมีกี่เศษ จะมีราคา ETH อย่างน้อยสองราคา หนึ่งคือราคาของ ETH บนเศษที่มีแอปพลิเคชันทางการเงินที่หรูหราที่สุด (นั่นคือ เศษ Eth1) อีกอันคือราคาของ ETH ในอีกอันหนึ่ง เศษชิ้นส่วนอย่างหลังต้องจ่ายค่าธรรมเนียมการจัดการจำนวนหนึ่งและจ่ายในระยะเวลาหนึ่งก่อนที่จะสามารถแลกเปลี่ยนกับชิ้นแรกได้ ดังนั้นจะต้องมีส่วนลดสำหรับชิ้นแรก ในทำนองเดียวกัน แม้ว่าจะมี uniswap ในแต่ละ Shard แต่ Transaction Slippage ของตลาดในแต่ละ Shard จะต้องแตกต่างกัน ในที่สุด ทุกคนจะมารวมกันที่ Shard เดียว เพราะเมื่อทุกคนอยู่ด้วยกันสภาพคล่องจะมีมากที่สุด และมีประสิทธิภาพสูงสุด.. ในระดับหนึ่ง ถือได้ว่ามีความจำเป็นเพียงเล็กน้อยสำหรับธุรกรรมข้ามชาร์ด แต่นี่ก็หมายความว่าความสามารถในการประมวลผลธุรกรรมที่ไม่ได้ใช้งานบนชาร์ดอื่นๆ นั้นไม่มีความหมายเลย

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

การแยกส่วนของการดำเนินการที่กระจัดกระจาย (เฟส 2) พิสูจน์ให้เห็นถึงความยากของมัน—ในอนาคตอันใกล้ เส้นทางนี้จะไม่ได้ผลลัพธ์ที่น่าพอใจ ถึงกระนั้น ฉันไม่คิดว่านักวิจัยของ Eth2.0 จะละทิ้งแผนงาน 3 เฟสโดยสิ้นเชิง Vitalik ยังเน้นย้ำว่าแผนงานที่เปลี่ยนแปลงนั้นเข้ากันได้กับเฟส 2 อย่างสมบูรณ์ แต่เฟส 2 ไม่ได้มีความสำคัญอีกต่อไป

แต่ในความเป็นจริงแล้ว การละทิ้งการดำเนินการแยกส่วนเป็นเส้นทางที่ Ethereum ควรเลือก

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

แผนการทำงาน Beacon Chain Roadmap

ในแผนงานใหม่ของ Ethereum 2.0 จุดที่โดดเด่นที่สุดคือ beacon chain block จะมีการทำธุรกรรมของ Eth1 shard ที่ผสานเข้าด้วยกัน นั่นคือ beacon chain มีฟังก์ชั่นการดำเนินการ ส่วนอื่น ๆ มีหน้าที่บันทึกข้อมูลเท่านั้น

อันที่จริง การวางตำแหน่งของ "การแบ่งกลุ่มข้อมูล" ในแผนการทำงานใหม่คือ "ชั้นความพร้อมใช้งานของข้อมูล (ความพร้อมใช้งานของข้อมูล) สำหรับการยกเลิก"

หากไม่มีการแบ่งส่วนปฏิบัติการ การปรับขนาดกำลังสองก็หมดปัญหา ดังนั้นความสามารถในการปรับขนาดของสถาปัตยกรรม "PoS Layer-1 + ข้อมูลการยกเลิก + ข้อมูลการยกเลิกไม่ใช้พื้นที่บล็อกเชนหลัก" คืออะไร

ในการตอบคำถามนี้ มาดูโหมดการโต้ตอบระหว่างโครงร่างการยกเลิกและห่วงโซ่หลัก

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

ลักษณะของการยกเลิก (เช่น zkRollup) ที่ใช้การพิสูจน์ความถูกต้องคือ: ทุกครั้งที่สัญญาเปิดเผยข้อมูลธุรกรรม จะมาพร้อมกับ "การพิสูจน์ความสมบูรณ์ของคอมพิวเตอร์" ว่าธุรกรรมเหล่านี้ได้รับการดำเนินการอย่างถูกต้อง ดังนั้นสถานะใหม่ควรเป็น XXX ถ้า หลักฐานสามารถผ่านการตรวจสอบของสัญญาได้ สัญญาจะอัปเดต state root หากหลักฐานไม่สามารถผ่านการตรวจสอบได้ สัญญาจะปฏิเสธที่จะอัปเดต

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

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

(1) วิธีการ "ดาวน์โหลดหากคุณต้องการดาวน์โหลดและอย่าดาวน์โหลดหากคุณไม่ต้องการดาวน์โหลด" นี้ใช้ไม่ได้กับ zk rollup: เมื่อ zk rollup ต้องการอัปเดตสถานะ root ตัวตรวจสอบของ การดำเนินการอัปเดตสัญญายกเลิก zk (นั่นคือ Layer- 1) จะต้องได้รับข้อมูลการทำธุรกรรมที่สอดคล้องกับการพิสูจน์เมื่อยอมรับการพิสูจน์ มิฉะนั้น จะไม่ผ่านการตรวจสอบ (ไม่จำเป็นต้องระบุข้อมูลธุรกรรม และยังมีโซลูชันเพื่อส่งเสริมรากของสถานะสัญญาด้วยการตรวจสอบหลักฐานที่เรียกว่า Validium ซึ่งไม่ใช่การยกเลิก) กล่าวอีกนัยหนึ่ง หากพิจารณาเพียง zk rollup ดังนั้นเมธอด "data sharding" จะไม่แตกต่างจากบล็อกขนาดใหญ่ในแง่ของแบนด์วิธ ไม่ว่าข้อมูลจะถูกส่งไปที่ใดและถูกเก็บไว้ที่ใด โหนดทั้งหมดจะต้องดาวน์โหลด

สรุปแล้ว

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

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

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

สรุปแล้ว

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