เมื่อผู้ใช้เริ่มรวม Avail เข้ากับการออกแบบเชนของตน ก็มักจะมีคำถามเกิดขึ้น: Avail สามารถจัดการธุรกรรมได้จำนวนเท่าใด ในบทความนี้ เราจะเปรียบเทียบ Ethereum และ Avail ตามสถาปัตยกรรมปัจจุบันของทั้งสองเชน ปริมาณงาน

นี่เป็นบทความแรกในชุดบทความเกี่ยวกับความสามารถในการปรับขนาดของ Avail โดยอภิปรายการประสิทธิภาพในปัจจุบันของ Avail และความสามารถในการปรับขนาดในระยะสั้นและระยะยาว

Avail vs Ethereum

บล็อกของ Ethereum สามารถเก็บข้อมูลได้มากถึง 1.875 MB และเวลาบล็อกคือประมาณ 13 วินาที อย่างไรก็ตาม บล็อก Ethereum มักจะไม่เต็ม เกือบทุกบล็อกจะไม่ถึงขีดจำกัดด้านบนของข้อมูลเนื่องจากการถึงขีดจำกัดของก๊าซ เนื่องจากทั้งการดำเนินการและการชำระบัญชีใช้ก๊าซ ดังนั้นจำนวนข้อมูลที่จัดเก็บในแต่ละบล็อกจึงแปรผัน

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

ปัจจุบัน เวลาบล็อกของ Avail คือ 20 วินาที และแต่ละบล็อกสามารถเก็บข้อมูลได้ประมาณ 2 MB สมมติว่าขนาดธุรกรรมเฉลี่ย 250 ไบต์ แต่ละบล็อก Avail ในปัจจุบันสามารถรองรับธุรกรรมได้ประมาณ 8,400 รายการ (420 ธุรกรรมต่อวินาที)

ยิ่งไปกว่านั้น Avail ยังสามารถเติมบล็อกได้จนถึงขีดจำกัดพื้นที่เก็บข้อมูลและเพิ่มขนาดได้ตามต้องการ เรามีคันโยกจำนวนหนึ่งที่สามารถปรับได้อย่างรวดเร็วเพื่อเพิ่มจำนวนธุรกรรมต่อบล็อกเป็นมากกว่า 500,000 (25,000 ธุรกรรมต่อวินาที) หากจำเป็น

เราสามารถเพิ่มปริมาณงานได้หรือไม่?

เพื่อเพิ่มปริมาณงาน (โดยเฉพาะธุรกรรมต่อวินาที) สถาปนิกของห่วงโซ่จำเป็นต้องเพิ่มขนาดบล็อกหรือลดเวลาบล็อก

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

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

ในทางกลับกัน ทรูพุตยังสามารถเพิ่มขึ้นได้โดยการเพิ่มขนาดบล็อก เช่น การเพิ่มปริมาณข้อมูลที่เราสามารถบรรจุได้ต่อบล็อก

สถาปัตยกรรมปัจจุบัน: การเพิ่มบล็อกให้กับเชน

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

1. การสร้างบล็อก

ขั้นตอนนี้รวมเวลาที่ต้องใช้ในการรวบรวมและจัดเรียงธุรกรรม Avail สร้างข้อผูกพัน และขยาย (ลบโค้ด) เมทริกซ์ข้อมูล

การสร้างบล็อกจะวัดเวลาที่ใช้ในการสร้างบล็อก เนื่องจากจะใช้เวลาอย่างน้อยระยะหนึ่งเสมอ ดังนั้นเราจึงต้องพิจารณาไม่เพียงแต่เวลากรณีที่ดีที่สุดเท่านั้น แต่ยังพิจารณาเวลากรณีเฉลี่ยและกรณีเลวร้ายที่สุดบนเครื่องที่แตกต่างกันด้วย

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

2. ความล่าช้าในการขยายพันธุ์

เวลาแฝงในการเผยแพร่คือการวัดเวลาที่ใช้ในการเผยแพร่บล็อกจากผู้ผลิตไปยังผู้ตรวจสอบและเครือข่ายเพียร์ทูเพียร์

ปัจจุบันขนาดบล็อกของ Avail คือ 2 MB ภายในขีดจำกัดเวลาบล็อกปัจจุบันที่ 20 วินาที ขนาดบล็อกดังกล่าวสามารถเผยแพร่ได้ ขนาดบล็อกที่ใหญ่ขึ้นทำให้การแพร่กระจายยุ่งยากมากขึ้น

ตัวอย่างเช่น ถ้าเราเพิ่ม Avail ให้รองรับบล็อก 128 MB การคำนวณอาจปรับขนาดได้ (ประมาณ 7 วินาที) อย่างไรก็ตาม ปัญหาคอขวดจะกลายเป็นเวลาที่ต้องใช้ในการส่งและดาวน์โหลดบล็อกเหล่านี้ผ่านเครือข่าย

การส่งบล็อกขนาด 128 MB ไปทั่วโลกผ่านเครือข่ายเพียร์ทูเพียร์ภายใน 5 วินาทีน่าจะเป็นขีดจำกัดของสิ่งที่สามารถทำได้ในปัจจุบัน

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

ความจำเป็นนี้เพื่อคำนึงถึงความล่าช้าในการแพร่กระจายจะทำให้เรามีขีดจำกัดขนาดบล็อกตามทฤษฎีในปัจจุบันของ Avail

3. บล็อคการยืนยัน

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

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

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

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

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

Discovery Data Availability Sampling ทำงานอย่างไร

ใน Avail ไคลเอ็นต์ light ใช้เครื่องมือหลักสามประการเพื่อยืนยันความพร้อมใช้งานของข้อมูล ได้แก่ ตัวอย่าง ข้อผูกพัน และการรับรอง

• ขณะนี้ไคลเอ็นต์ Light ดำเนินการตัวอย่าง โดยจะขอค่าของเซลล์เฉพาะและใบรับรองความถูกต้องที่เกี่ยวข้องจากเครือข่าย Avail ยิ่งพวกเขาเก็บตัวอย่างได้มากเท่าไร พวกเขาก็ยิ่งมั่นใจมากขึ้นว่าข้อมูลทั้งหมดจะพร้อมใช้งาน

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

• ทุกเซลล์ในเครือข่ายจะสร้างข้อพิสูจน์ ลูกค้า Light ใช้การพิสูจน์และสัญญาว่าจะตรวจสอบว่าค่าของเซลล์ที่ให้ไว้นั้นถูกต้อง

เมื่อใช้เครื่องมือเหล่านี้ ไคลเอ็นต์แบบ light จะดำเนินการสามขั้นตอน

• การตัดสินใจ: ความเชื่อมั่นด้านความพร้อมใช้งานที่จำเป็นจะกำหนดจำนวนตัวอย่างที่ดำเนินการโดยไคลเอ็นต์แบบ light พวกเขาไม่ต้องการตัวอย่างจำนวนมาก (8-30 ตัวอย่าง) เพื่อรับประกันความพร้อมใช้งานมากกว่า 99.95%

• ดาวน์โหลด: จากนั้นไคลเอ็นต์ light จะขอตัวอย่างเหล่านี้และข้อพิสูจน์ที่เกี่ยวข้อง และดาวน์โหลดจากเครือข่าย (โหนดแบบเต็มหรือไคลเอ็นต์ light อื่นๆ)

• การตรวจสอบ: จะดูที่ความมุ่งมั่นในส่วนหัวของบล็อก (ซึ่งไคลเอ็นต์แบบ light สามารถเข้าถึงได้ตลอดเวลา) และตรวจสอบหลักฐานของแต่ละเซลล์เทียบกับข้อผูกพัน

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

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