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

Rollup ของแอปเป็นการใช้งานแบบเริ่มใช้แล้วสำหรับกรณีการใช้งานเหล่านี้จำนวนมาก อย่างไรก็ตาม การใช้งานการยกเลิกมาตรฐาน เช่น การยกเลิก EVM ยังคงมีข้อจำกัดด้านความสามารถในการปรับขนาดที่สำคัญ พวกเขาอาจบรรลุปริมาณงานได้ประมาณ 100 ธุรกรรมต่อวินาที ปริมาณงานดังกล่าวอาจเพียงพอสำหรับเกมออนไลน์บางเกม ขึ้นอยู่กับประเภทของเกม อย่างไรก็ตาม เกมส่วนใหญ่ต้องการปริมาณงานที่สูงกว่ามากเพื่อรองรับผู้เล่นพร้อมกันจำนวนมาก (> 1,000) บทความนี้มุ่งเน้นไปที่แนวทางการปรับขนาดการรวบรวมแอปเพื่อเข้าถึงผู้เข้าร่วมพร้อมกันหลายแสนคน สำหรับแต่ละแนวทาง ฉันจะหารือเกี่ยวกับประเภทของแอปพลิเคชัน/เกมที่เหมาะสม และความท้าทายที่เผชิญอยู่

ผู้สร้างที่ใช้การรวบรวมแอปหรือผู้ที่กำลังสร้างโครงสร้างพื้นฐานเพื่อปรับขนาดการรวบรวมแอป ควรติดต่อ ฉัน และสมัครกับ Alliance ฉันหวังว่าจะได้ร่วมงานกับผู้ก่อตั้งอาคารในพื้นที่เหล่านี้

การปรับขนาดแนวนอน

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

ความสามารถในการปรับขนาดในแนวนอนหมายถึงเพียงปรับใช้การรวบรวมแอปหลายรายการ (OP หรือ ZK) โดยมีสัญญาอัจฉริยะแบบเดียวกันปรับใช้กับการยกเลิกทั้งหมด ส่วนหน้าของแอปพลิเคชันจะนำผู้ใช้ไปยังชุดรวมอัปเดตอย่างใดอย่างหนึ่งได้อย่างราบรื่น โดยขึ้นอยู่กับความจุ ตำแหน่ง หรือตัวเลือกแอปพลิเคชันเฉพาะ เมื่อเร็วๆ นี้ Alt Layer ได้สาธิตแนวคิดนี้ด้วยการเปิดตัว FOCG 2048 ที่ปรับขนาดได้ ในส่วนหน้าของเกม ผู้ใช้มีตัวเลือกในการเลือกชุดรวมที่จะเข้าร่วมตามตำแหน่งทางภูมิศาสตร์ เนื่องจากความเรียบง่ายและความพร้อมใช้งานของผู้ให้บริการ Rollup-as-a-service เช่น Caldera ที่จัดการงานโครงสร้างพื้นฐานทั้งหมดที่เกี่ยวข้องกับการหมุนเวียนและการจัดการ Rollup เหล่านี้ ผู้พัฒนาเกมจึงสามารถนำแนวทางนี้ไปใช้ได้อย่างง่ายดาย

แม้จะเรียบง่าย แต่ก็ยังมีปัญหาบางประการในแนวทางการปรับขนาดแบบหลายม้วน ประการแรกคือการสลับเครือข่ายแบบสะสม กระเป๋าเงินปัจจุบัน เช่น Metamask จำเป็นต้องได้รับการอนุมัติด้วยตนเองเพื่อเชื่อมต่อกับเครือข่ายใหม่ เช่น อินสแตนซ์แบบสะสม สิ่งนี้นำไปสู่ประสบการณ์ผู้ใช้ที่ยากลำบากและสับสนสำหรับผู้เล่นที่ต้องเชื่อมต่อกับ "เครือข่าย" หลายแห่งด้วยตนเองเพื่อเล่นเกมเดียวกัน โชคดีที่คุณสามารถ สรุปความซับซ้อนนี้ ได้ด้วยโซลูชัน AA เช่น EIP 4337 และกระเป๋าเงินแบบฝัง เช่น Privy และ 0xPass

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

ช่องของรัฐ ZK

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

ในกรณีนี้ การรวบรวมแอปแสดงถึงชั้นข้อมูลที่แชร์ซึ่งจัดเก็บผลลัพธ์ของเกมและตำแหน่งของเนื้อหาของเกม สำหรับแต่ละเกมในภาพรวม สามารถเริ่ม ZK State Channel เพื่อให้บริการเกมนี้ได้ ในระหว่างการเล่นเกม ผู้เล่นแต่ละคนจะสร้างธุรกรรมและสร้าง ZKP เพื่อพิสูจน์ว่าพวกเขาได้ปฏิบัติตามกฎของเกม การพิสูจน์จากการโต้ตอบของผู้เล่นรายอื่นจะรวมการพิสูจน์ก่อนหน้านี้โดยใช้การพิสูจน์อักษรแบบเรียกซ้ำ เมื่อเกมจบลง ZKP สุดท้ายจะถูกส่งไปยังการรวบรวมแอปเพื่อพิสูจน์ความถูกต้องของการเล่นเกมและความถูกต้องของผลลัพธ์สุดท้าย การเปลี่ยนแปลงสถานะที่เกิดขึ้นจากเกมจะเปลี่ยนสถานะของผู้เล่นในการรวบรวมแอป

ช่องทางของรัฐ ZK ย้ายการโต้ตอบของเกมนอกเครือข่าย ดังนั้น กิจกรรมและธุรกรรมในเกมจะไม่นับรวมกับปริมาณงานของการรวบรวมแอป เมื่อใช้วิธีการนี้ การรวบรวมแอปสามารถขยายขนาดได้อย่างมากเพื่อรองรับผู้เล่นหลายหมื่นหรือหลายแสนคนพร้อมกัน ธุรกรรมการรวบรวมแอปจะเป็นเพียงการตรวจสอบ ZKP ที่สร้างขึ้นและธุรกรรมการอัปเดตสถานะที่ส่งผลให้มีปัจจัยการปรับขนาด 100–1000x หลายทีมรวมถึง Ontropy มุ่งเน้นไปที่การพัฒนาเทคโนโลยีนี้

ข้อเสียของแนวทางนี้คือผู้เล่นต้องใช้ตรรกะของเกมและสร้าง ZKP บนอุปกรณ์ของตน บ่อยครั้งที่การพิสูจน์เหล่านี้มีน้ำหนักเบา และด้วยการใช้ประโยชน์จากระบบการพิสูจน์ที่ล้ำสมัย เช่น Halo2 การพิสูจน์อาจใช้เวลาน้อยกว่าไม่กี่วินาที อย่างไรก็ตาม สิ่งนี้อาจยังส่งผลให้ UX เสื่อมลงสำหรับผู้เล่นที่มีอุปกรณ์จำกัดทรัพยากร

การปรับเปลี่ยนแนวทางนี้ที่สามารถบรรเทาปัญหานี้ได้คือการกำหนดหนึ่งในผู้เข้าร่วมช่องสถานะ zk เป็นซีเควนเซอร์ชั่วคราว ซีเควนเซอร์นี้จะได้รับธุรกรรมของผู้เล่นแต่ละคน และสร้าง ZKP ที่เกี่ยวข้อง และแบ่งปัน ZKP กับผู้เข้าร่วมช่องทั้งหมด การปรับเปลี่ยนนี้ถือได้ว่าเป็น ZK L3 ชั่วคราวซึ่งจะชำระให้กับการยกเลิกแอป ทีมงาน คาร์ทริดจ์ ได้นำสถาปัตยกรรมนี้ไปใช้โดยการออกแบบซีเควนเซอร์พิเศษที่เรียกว่า Katana

วิธีการช่องทางสถานะ zk มีศักยภาพมากมาย อย่างไรก็ตาม มีคำถามเปิดหลายข้อที่เกี่ยวข้องกับสภาพแวดล้อมการดำเนินการภายในช่องทางสถานะ zk และวิธีการปรับให้เหมาะสมสำหรับการเรียกซ้ำเพื่อพิสูจน์ สภาพแวดล้อม zkEVM ปัจจุบันไม่มีประสิทธิภาพมากนัก และส่วนใหญ่ไม่รองรับการพิสูจน์การเรียกซ้ำในปัจจุบัน ทางเลือกอื่น ได้แก่ zkVM แบบน้ำหนักเบา หรือแม้แต่การใช้วงจร zk เฉพาะสำหรับการโต้ตอบกับผู้เล่น หากจำนวนการดำเนินการที่เป็นไปได้สำหรับผู้เล่นมีจำกัด

การเปลี่ยนแปลงสภาพแวดล้อมการดำเนินการ

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

ข้อได้เปรียบหลักของแนวทางนี้คือการปรับปรุงปริมาณการประมวลผลแบบรวมไม่จำเป็นต้องลดทอนความสามารถในการประกอบหรือจำกัดจำนวนกรณีการใช้งาน วิธีการนี้สามารถใช้ได้กับแอปพลิเคชัน Web 3 ใดๆ ตราบใดที่สภาพแวดล้อมการดำเนินการสามารถบรรลุปริมาณงานที่แอปพลิเคชันต้องการ ทำให้เป็นโซลูชันเดียวที่ใช้งานได้สำหรับแอปพลิเคชันที่ต้องการเข้าถึงสถานะที่ใช้ร่วมกัน เช่น AMM โปรโตคอลการให้ยืม และแอปพลิเคชัน DeFi อื่นๆ

ขยายฟังก์ชัน EVM ผ่านทางพรีคอมไพล์

แนวทางแรกคือให้การยกเลิกยังคงเข้ากันได้กับ EVM และแก้ไขข้อจำกัดด้านปริมาณงานบางส่วนผ่านการคอมไพล์ล่วงหน้า แนวคิดที่นี่เป็นเรื่องง่าย พรีคอมไพล์เป็นเพียงการย้ายการดำเนินการ EVM ที่มีราคาแพงในการคำนวณลงไปที่ระดับโหนด การดำเนินการที่ต้องใช้ EVM OP หลายร้อยหรือหลายพันรายการและใช้ก๊าซมากกว่า 100,000 รายการสามารถทำให้ง่ายขึ้นเป็นการดำเนินการเดียวโดยมีค่าใช้จ่ายด้านก๊าซลดลง 100 เท่า การขยายสภาพแวดล้อมการยกเลิกด้วยพรีคอมไพล์มักเรียกว่า EVM+ ตัวอย่างของแนวทางนี้ได้แก่ การสนับสนุนความเป็นส่วนตัวแบบออนไลน์ และการสนับสนุนรูปแบบลายเซ็นที่มีประสิทธิภาพมากขึ้น เช่น ลายเซ็น BLS ตัวอย่างเช่น เกมโป๊กเกอร์ zkHoldem ใช้การดำเนินการ FHE และ zk แบบพิเศษเพื่อให้บรรลุการจัดการและเปิดเผยไพ่โป๊กเกอร์ส่วนตัว การพัฒนาพรีคอมไพล์เฉพาะทางเหล่านี้มักเป็นความพยายามร่วมกันระหว่างนักพัฒนาชุดสะสมแอปและผู้ให้บริการ Raas ที่จัดการการปรับใช้และการบำรุงรักษาชุดรวมแอปอินฟาเรด

การใช้สภาพแวดล้อมการดำเนินการที่ไม่ใช่ EVM

อีกวิธีหนึ่งในการปรับปรุงสภาพแวดล้อมการดำเนินการควบรวมคือการแยกตัวออกจาก EVM แนวทางนี้กำลังได้รับความนิยมมากขึ้นในหมู่นักพัฒนาที่ยังใหม่กับระบบนิเวศ Ethereum และนักพัฒนาที่เชื่อว่า Solidity ไม่ใช่ภาษาที่ดีที่สุดในการพัฒนาแอปพลิเคชันที่ซับซ้อน

ปัจจุบัน เรามีแอปพลิเคชันแบบรวมที่ทำงานบน WASM, SVM, Cairo และแม้แต่รันไทม์ของ Linux วิธีการเหล่านี้ส่วนใหญ่ช่วยให้นักพัฒนาสามารถเขียนสัญญาอัจฉริยะในภาษาระดับสูง เช่น Rust หรือ C ได้ ข้อเสียคือความสามารถในการทำงานร่วมกันกับสัญญา Solidity ที่มีอยู่มักจะสูญหายไป อย่างไรก็ตาม ยังคงสามารถสร้างความเข้ากันได้กับ EVM ได้ ตัวอย่างเช่น สไตลัสของ Aributrum ใช้โปรเซสเซอร์ร่วมเพื่อทำให้สัญญาสไตลัสเข้ากันได้กับ EVM การออกแบบนี้ทำให้สไตลัสเข้าใกล้สถาปัตยกรรม EVM+ มากกว่าที่ไม่ใช่ EVM

สภาพแวดล้อมการดำเนินการแบบไฮบริด

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

ข้อดีของแนวทางนี้คือความเข้ากันได้ของ EVM ช่วยให้มั่นใจได้ว่ามีความสอดคล้องกับระบบนิเวศที่ใหญ่ขึ้นของ devs และผลิตภัณฑ์ที่มีอยู่ นอกจากนี้ยังอนุญาตให้มีการเขียนองค์ประกอบโดยไม่ได้รับอนุญาต นักพัฒนาสามารถดัดแปลงและขยายตรรกะของเกมได้โดยการเพิ่มสัญญาอัจฉริยะ EVM/solidity ในขณะเดียวกัน เอ็นจิ้นเกมพิเศษที่ไม่ใช่ EVM ก็มีปริมาณงานสูงซึ่ง EVM ไม่สามารถตอบสนองได้

ตัวอย่างของแนวทางนี้คือ World Engine จาก Argus และ Keystone จาก Curio World Engine แยกการทำงานของตรรกะของเกมออกเป็นเลเยอร์แยกต่างหากที่เรียกว่า Game Shard ซึ่งทำงานบนเลเยอร์ที่เข้ากันได้กับ EVM Game Shard ยังได้รับการออกแบบมาเพื่อให้สามารถปรับขนาดแนวนอนเพื่อปรับปริมาณงานรวมทั้งหมดได้ตามความต้องการ ในทำนองเดียวกัน สถาปัตยกรรม Keystone ของ Curio รวมเอ็นจิ้นเกมที่มีปริมาณงานสูงเข้ากับ EVM เป็นสภาพแวดล้อมการดำเนินการแบบโรลอัพ ความท้าทายที่นี่คือเพื่อให้บรรลุการทำงานร่วมกันอย่างราบรื่นระหว่างเอ็นจิ้น EVM และเอ็นจิ้นเกม

ข้อควรพิจารณาเกี่ยวกับความพร้อมใช้งานของข้อมูล

ในการสนทนาครั้งก่อน จุดเน้นอยู่ที่ประเด็นหลักของการปรับขนาดการรวบรวมแอป ซึ่งเป็นการเพิ่มปริมาณงานธุรกรรมการรวบรวม มีหัวข้ออื่นๆ ที่เกี่ยวข้องกับปริมาณงานที่เพิ่มขึ้นนี้ เช่น ความพร้อมใช้งานของข้อมูล (DA) การกระจายอำนาจของซีเควนเซอร์ และความเร็วในการชำระหนี้ ความพร้อมใช้งานของข้อมูลเป็นปัญหาเร่งด่วนที่สุดสำหรับการยกเลิกแอปที่มีปริมาณงานสูง

การรวบรวมแอปเดียวอาจมีปริมาณงานเกิน 10,000 tps การใช้ Ethereum เป็นเลเยอร์ DA สำหรับธุรกรรมเหล่านี้เป็นไปไม่ได้ ประการแรก ต้นทุนเฉลี่ยในการเผยแพร่ข้อมูลของการโอน L2 ETH แบบธรรมดาบน L1 สามารถเกิน 0.10 ดอลลาร์ได้ ค่าใช้จ่ายเหล่านี้สูงเกินไปสำหรับการยกเลิกแอปส่วนใหญ่ ที่สำคัญกว่านั้น ปัจจุบัน L1 ของ Ethereum ไม่สามารถรองรับ TPS มากกว่า 8k TPS [1] โดยประมาณสำหรับโรลอัพที่ใช้ L1 สำหรับ DA

การยกเลิกแอปจะขึ้นอยู่กับโซลูชัน DA ภายนอกเป็นหลัก ปัจจุบัน Celestia และ EigenDA อยู่ในตำแหน่งที่เป็นตัวเลือกที่เป็นไปได้มากที่สุดสำหรับการรวบรวมแอป ตัวอย่างเช่น Eclipse วางแผนที่จะใช้ Celestia สำหรับการยกเลิกตาม SVM ที่มีปริมาณงานสูง อาร์กัสและเอ็นจิ้นเกมความเร็วสูงมีแผนที่จะใช้ Celestia ในตอนแรกเช่นกัน ในทำนองเดียวกัน EigenDA ซึ่งรับประกันปริมาณข้อมูลสูงสุด 10MB/วินาที อาจเป็นโซลูชันที่ใช้ได้สำหรับการรวบรวมแอปหลายรายการ

อย่างไรก็ตาม การบูรณาการ Celestia หรือ EigneDA มีข้อเสียเปรียบหลักคือการรั่วไหลของมูลค่าทางเศรษฐกิจ การยกเลิกแอปจะต้องชำระค่าธรรมเนียมสำหรับเลเยอร์ DA นอกเหนือจากค่าธรรมเนียมการชำระบัญชีบน Ethereum L1 ค่าธรรมเนียมการชำระบัญชีมีความสำคัญอย่างยิ่งต่อการยกเลิกแอป เนื่องจากจะปรับความปลอดภัยของการยกเลิกให้สอดคล้องกับความปลอดภัยของ Ethereum การรับประกันของ DA มีความสำคัญน้อยกว่าโดยเฉพาะในบริบทของ FOG ซึ่งมูลค่าธุรกรรมน้อยกว่ามาก นอกจากนี้ Celestia และ EigenDA ยังสัญญาว่าจะมีค่าธรรมเนียมต่ำ เนื่องจากเครือข่ายเหล่านี้เป็นเครือข่ายใหม่และจะมีการใช้งานต่ำในช่วงแรก เมื่อเครือข่าย DA เหล่านี้มีการใช้งานสูง ค่าธรรมเนียม DA ก็อาจสูงเกินไปได้เช่นกัน ในความคิดของฉัน การรวบรวมแอปควรใช้ Data Availability Committee (DAC) แบบธรรมดาแทนเพื่อยืนยันความพร้อมใช้งานของข้อมูล Rollup[3]

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

ฉันขอขอบคุณ Matt Katz, Kevin Zhang, Tarrence van As และ Larry Liu สำหรับคำติชมอันมีค่าของพวกเขาเกี่ยวกับบทความนี้

[1] สมมติว่า 50% ของขีดจำกัด Block Gas ของ Ethereum จะเป็นเพียงการจัดเก็บข้อมูลโดยใช้ Calldata ขนาด tx เฉลี่ย 10 ไบต์ เวลาบล็อก 12 วินาที

ข้อสงวนสิทธิ์：

1. บทความนี้พิมพ์ซ้ำจาก [Alliance] ลิขสิทธิ์ทั้งหมดเป็นของผู้แต่งต้นฉบับ [Mohamed Fouda] หากมีการคัดค้านการพิมพ์ซ้ำนี้ โปรดติดต่อทีมงาน Gate Learn แล้วพวกเขาจะจัดการโดยเร็วที่สุด
2. การปฏิเสธความรับผิด: มุมมองและความคิดเห็นที่แสดงในบทความนี้เป็นเพียงของผู้เขียนเท่านั้น และไม่ถือเป็นคำแนะนำในการลงทุนใดๆ
3. การแปลบทความเป็นภาษาอื่นดำเนินการโดยทีมงาน Gate Learn เว้นแต่จะกล่าวถึง ห้ามคัดลอก แจกจ่าย หรือลอกเลียนแบบบทความที่แปลแล้ว