เหตุใดประสิทธิภาพของบล็อคเชนจึงวัดได้ยาก

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

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

ความสามารถในการปรับขนาดเทียบกับประสิทธิภาพ

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

ความแตกต่างนี้มีความสำคัญ: วิธีการมากมายในการปรับปรุงประสิทธิภาพไม่ได้ปรับปรุงความสามารถในการปรับขนาดเลย เมื่อกำหนดไว้อย่างเหมาะสม ตัวอย่างง่ายๆ คือการใช้รูปแบบลายเซ็นดิจิทัลที่มีประสิทธิภาพมากขึ้น เช่น ลายเซ็น BLS ซึ่งมีขนาดประมาณครึ่งหนึ่งของลายเซ็น Schnorr หรือ ECDSA หาก Bitcoin เปลี่ยนจาก ECDSA เป็น BLS จำนวนธุรกรรมต่อบล็อกอาจเพิ่มขึ้น 20-30% ซึ่งช่วยปรับปรุงประสิทธิภาพในชั่วข้ามคืน แต่เราทำได้เพียงครั้งเดียวเท่านั้น — ไม่มีรูปแบบลายเซ็นที่มีพื้นที่ว่างมากพอที่จะเปลี่ยนไปใช้ (สามารถรวมลายเซ็น BLS เพื่อประหยัดพื้นที่ได้มากขึ้น แต่นี่เป็นเคล็ดลับแบบใช้ครั้งเดียวเท่านั้น)

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

การทำความเข้าใจความแตกต่างยังช่วยหลีกเลี่ยงข้อผิดพลาดทั่วไปของหมวดหมู่ที่พบในข้อความสั่ง เช่น “Blockchain X สามารถปรับขนาดได้สูง สามารถรองรับธุรกรรม Y ต่อวินาที!” การอ้างสิทธิ์ครั้งที่สองอาจน่าประทับใจ แต่ก็เป็น การปฏิบัติ ตัววัด ไม่ใช่ตัววัดความสามารถในการขยาย ไม่ได้พูดถึงความสามารถในการปรับปรุงประสิทธิภาพโดยการเพิ่มทรัพยากร

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

เวลาในการตอบสนองเทียบกับปริมาณงาน

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

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

ความท้าทายในการวัดเวลาแฝง

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

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

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

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

แม้ว่าเราจะกำหนดกรอบเวลาที่เรากำลังพยายามวัดด้วยความหน่วง แต่คำตอบก็เกือบทุกครั้ง มันขึ้นอยู่กับ. ไม่มีระบบสกุลเงินดิจิทัลที่เคยสร้างมาซึ่งให้เวลาแฝงของธุรกรรมคงที่ กฎพื้นฐานที่ควรจำคือ:

เวลาแฝงคือการแจกแจง ไม่ใช่ตัวเลขเดียว

ชุมชนการวิจัยเครือข่ายเข้าใจเรื่องนี้มานานแล้ว (ดูตัวอย่าง this คำพูดที่ยอดเยี่ยมโดย Gil Tene). มีการเน้นเป็นพิเศษที่ "หางยาว" ของการกระจาย เนื่องจากเวลาแฝงที่ยกระดับสูงในธุรกรรม 0.1% (หรือการสืบค้นเว็บเซิร์ฟเวอร์) จะรุนแรง ส่งผลกระทบ ผู้ใช้ปลายทาง

ด้วยบล็อคเชน เวลาแฝงในการยืนยันอาจแตกต่างกันไปด้วยเหตุผลหลายประการ:

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

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

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

ด้วยเหตุผลเหล่านี้ แนวทางที่ดีคือ:

การอ้างสิทธิ์เกี่ยวกับเวลาแฝงควรแสดงการแจกแจง (หรือฮิสโตแกรม) ของเวลาการยืนยัน แทนที่จะเป็นตัวเลขเดียว เช่น ค่าเฉลี่ยหรือค่ามัธยฐาน

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

เครือข่ายช่องทางการชำระเงิน (เช่น Lightning Network) เป็นตัวอย่างที่ดี โซลูชันการปรับขนาด L2 แบบคลาสสิก เครือข่ายเหล่านี้ให้การยืนยันการชำระเงินที่รวดเร็วเกือบตลอดเวลา แต่ในบางครั้ง พวกเขาต้องการการรีเซ็ตช่องสัญญาณ ซึ่งสามารถเพิ่มเวลาในการตอบสนองตามลำดับความสำคัญได้

และแม้ว่าเราจะมีสถิติที่ดีเกี่ยวกับการกระจายเวลาแฝงที่แน่นอน แต่ก็มีแนวโน้มที่จะเปลี่ยนแปลงไปตามกาลเวลาเมื่อระบบและความต้องการในระบบเปลี่ยนไป ยังไม่ชัดเจนว่าจะเปรียบเทียบการกระจายเวลาแฝงระหว่างระบบที่แข่งขันกันอย่างไร ตัวอย่างเช่น พิจารณาระบบหนึ่งที่ยืนยันธุรกรรมที่มีเวลาแฝงแบบกระจายสม่ำเสมอระหว่าง 1 ถึง 2 นาที (โดยมีค่าเฉลี่ยและค่ามัธยฐาน 90 วินาที) หากระบบที่แข่งขันกันยืนยัน 95% ของการทำธุรกรรมใน 1 นาที และอีก 5% ใน 11 นาที (ด้วยค่าเฉลี่ย 90 วินาทีและค่ามัธยฐาน 60 วินาที) ระบบไหนดีกว่ากัน? คำตอบอาจเป็นได้ว่าแอปพลิเคชั่นบางตัวอาจชอบรุ่นก่อนและรุ่นหลัง

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

เวลาแฝงมีความซับซ้อน ยิ่งรายงานข้อมูลมากเท่าไหร่ก็ยิ่งดีเท่านั้น ตามหลักการแล้ว การกระจายเวลาแฝงที่สมบูรณ์ควรวัดภายใต้สภาวะความแออัดที่แตกต่างกัน การแยกส่วนของเวลาในการตอบสนองออกเป็นส่วนประกอบต่างๆ (ในพื้นที่ เครือข่าย การแบทช์ ความล่าช้าตามมติ) ก็มีประโยชน์เช่นกัน

ความท้าทายในการวัดปริมาณงาน

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

ในขณะที่ “ธุรกรรมต่อวินาที” (หรือ tps) เป็นมาตรฐานโดยพฤตินัยสำหรับการวัดประสิทธิภาพของบล็อคเชน ธุรกรรมนั้นเป็นปัญหาในฐานะหน่วยวัด สำหรับระบบที่นำเสนอความสามารถในการตั้งโปรแกรมสำหรับวัตถุประสงค์ทั่วไป ("สัญญาอัจฉริยะ") หรือแม้แต่คุณสมบัติที่จำกัด เช่น ธุรกรรมมัลติเพล็กซ์ของ Bitcoin หรือตัวเลือกสำหรับการตรวจสอบหลายซิก ปัญหาพื้นฐานคือ:

ธุรกรรมทั้งหมดไม่เท่ากัน

สิ่งนี้เป็นจริงใน Ethereum โดยที่ธุรกรรมสามารถรวมรหัสโดยอำเภอใจและแก้ไขสถานะโดยพลการ แนวคิดของก๊าซใน Ethereum ใช้เพื่อวัดปริมาณ (และเรียกเก็บค่าธรรมเนียมสำหรับ) ปริมาณงานโดยรวมที่ทำธุรกรรม แต่สิ่งนี้มีความเฉพาะเจาะจงอย่างมากสำหรับสภาพแวดล้อมการดำเนินการ EVM ไม่มีวิธีง่ายๆ ในการเปรียบเทียบจำนวนงานทั้งหมดที่ทำโดยชุดธุรกรรม EVM กับชุดของธุรกรรม Solana โดยใช้สภาพแวดล้อม BPF การเปรียบเทียบทั้งชุดของธุรกรรม Bitcoin นั้นเต็มไปด้วยความคล้ายคลึงกัน

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

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

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

โดยรวม:

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

การประนีประนอมกับปริมาณงาน

เวลาแฝงและปริมาณงานมักจะเป็นการประนีประนอม เนื่องจาก Lefteris Kokoris-Kogias เค้าร่างการแลกเปลี่ยนนี้มักจะไม่ราบรื่น โดยมีจุดเปลี่ยนที่เวลาแฝงเพิ่มขึ้นอย่างรวดเร็วเมื่อโหลดของระบบเข้าใกล้ปริมาณงานสูงสุด

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

ค่าธรรมเนียมการทำธุรกรรม

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

1. ความต้องการของตลาดในการทำธุรกรรมมีมากน้อยเพียงใด?
2. ระบบได้ปริมาณงานโดยรวมเท่าใด
3. ระบบให้รายได้โดยรวมแก่ผู้ตรวจสอบความถูกต้องหรือผู้ขุดแร่เป็นจำนวนเท่าใด
4. รายได้นี้คำนวณจากค่าธรรมเนียมการทำธุรกรรมเทียบกับผลตอบแทนที่เป็นอัตราเงินเฟ้อเท่าใด

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

โดยเฉพาะอย่างยิ่ง จุดที่ 3 และ 4 ข้างต้นเป็นคำถามพื้นฐานของการออกแบบระบบบล็อกเชน แต่เราขาดหลักการที่ดีสำหรับข้อใดข้อหนึ่ง เรามีความเข้าใจในข้อดีและข้อเสียของการให้รายได้แก่นักขุดจากผลตอบแทนที่เป็นอัตราเงินเฟ้อเทียบกับค่าธรรมเนียมการทำธุรกรรม อย่างไรก็ตาม แม้จะมีการวิเคราะห์ทางเศรษฐกิจมากมายของโปรโตคอลฉันทามติบล็อคเชน เรายังไม่มีแบบจำลองที่ยอมรับกันอย่างกว้างขวางสำหรับรายได้ที่ต้องส่งไปยังผู้ตรวจสอบความถูกต้อง ทุกวันนี้ ระบบส่วนใหญ่ใช้การคาดเดาอย่างมีการศึกษาว่ามีรายได้มากเพียงใดเพียงพอที่จะทำให้ผู้ตรวจสอบมีพฤติกรรมที่ตรงไปตรงมาโดยไม่ต้องบีบคอการใช้งานระบบในทางปฏิบัติ ในแบบจำลองอย่างง่าย สามารถแสดงให้เห็นได้ว่าค่าใช้จ่ายในการเพิ่มการโจมตี 51% จะเพิ่มขึ้นพร้อมกับรางวัลสำหรับผู้ตรวจสอบ.

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

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

สรุป

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

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