การเพิ่มประสิทธิภาพของบล็อกเชน: ปัญหาคอขวดที่สำคัญ

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

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

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

Scalability Trilemma และขีดจำกัดของ Throughput

Scalability Trilemma น่าจะเป็นคอขวดที่รู้จักกันดีที่สุดในโลกของบล็อกเชน ทฤษฎีสามเหลี่ยมบล็อกเชนของ Vitalik ระบุว่าบล็อกเชนสามารถมีคุณสมบัติได้เพียง 2 จาก 3 ประการต่อไปนี้เท่านั้น ได้แก่ การกระจายศูนย์ (decentralization), ความปลอดภัย (security) และความสามารถในการขยายตัว (scalability) คุณไม่สามารถทำให้ทุกอย่างอยู่ในระดับสูงสุดพร้อมกันได้ นี่ไม่ใช่กฎที่ถูกกำหนดไว้ในอัลกอริทึม แต่มันคือข้อจำกัดตามธรรมชาติในการทำงานของเครือข่ายแบบกระจายศูนย์

หากคุณต้องการเครือข่ายที่รวดเร็วมาก (ขยายขนาดได้) และมีความปลอดภัย คุณมักจะต้องยอมแลกด้วยการลดความเป็นกระจายศูนย์ (decentralization) ลง โดยการมีจำนวนโหนดที่ตรวจสอบธุรกรรมน้อยลง คุณมีข้อแลกเปลี่ยนที่ต้องเลือก: หากคุณต้องการให้เครือข่ายมีความกระจายศูนย์และมีความปลอดภัยไปพร้อมกัน เช่น Bitcoin หรือ Ethereum คุณก็ต้องยอมสละเรื่องความเร็ว นี่คือเหตุผลที่ Bitcoin สามารถประมวลผลได้ประมาณ 7 ธุรกรรมต่อวินาที (TPS) และ Ethereum ทำได้ประมาณ 15 — 30 TPS ในเลเยอร์พื้นฐาน ในขณะที่ Visa สามารถรองรับได้ถึงหลักหมื่นธุรกรรม

ในจุดนี้ คอขวดคือขนาดของบล็อกและเวลาในการสร้างบล็อก วิธีแก้ปัญหาที่ง่ายและชัดเจนในการเพิ่มขีดความสามารถในการรองรับธุรกรรม (throughput) คือการขยายขนาดบล็อกให้ใหญ่ขึ้นเพื่อบรรจุธุรกรรมได้มากขึ้น หรือลดเวลาในการสร้างบล็อกเพื่อให้เราขุดบล็อกได้เร็วขึ้น แต่ในจุดนี้เราจะพบกับข้อจำกัดทางกายภาพ นั่นคือ ความล่าช้าในการแพร่กระจายข้อมูล (propagation delay) เมื่อนักขุดหรือผู้ตรวจสอบ (validator) ค้นพบบล็อกใหม่ บล็อกนั้นจะต้องถูกส่งไปยังโหนดอื่นๆ ทุกโหนดในเครือข่าย ข้อมูลเหล่านี้เดินทางผ่านสายเคเบิลอินเทอร์เน็ต ใยแก้วนำแสง และเราเตอร์ทั่วโลก แน่นอนว่ามันมีขีดจำกัด ทั้งความเร็วแสงและแบนด์วิดท์ของโครงสร้างพื้นฐานอินเทอร์เน็ต หากบล็อกมีขนาดใหญ่เกินไป อาจต้องใช้เวลานานขึ้นในการดาวน์โหลดและตรวจสอบ หากมีการสร้างบล็อกจำนวนมากเกินไปและเร็วเกินไปโดยนักขุดหลายรายพร้อมกัน ในขณะที่บล็อกก่อนหน้ายังแพร่กระจายไปไม่ทั่วถึง ก็จะนำไปสู่การเกิด "forks" หรือ "orphan blocks" (หรือที่ใน Ethereum เรียกว่า "uncles")

อัตราการเกิด uncle ที่สูงบ่งบอกว่าเครือข่ายกำลังสูญเสียกำลังการประมวลผลไปกับบล็อกที่ไม่ได้เข้าสู่สายหลัก ซึ่งทำให้ความปลอดภัยลดลงเนื่องจากกำลังการแฮช (hashing power) ที่ซื่อสัตย์ถูกแบ่งแยกออกไป ดังนั้น การจำกัด TPS จึงเป็นเสมือนการจำกัดการประสานข้อมูลของเครือข่าย (network synchronisation limit) นอกจากนี้ ทุกบล็อกยังมี "ขีดจำกัดแก๊ส" (gas limit) หรือ "น้ำหนักบล็อก" (block weight) ซึ่งไม่ได้มีไว้เพื่อจำกัดปริมาณธุรกรรมเท่านั้น แต่ยังเพื่อป้องกันการโจมตีแบบ Denial of Service (DoS) อีกด้วย หากไม่มีการกำหนดขีดจำกัดของปริมาณการประมวลผลที่บล็อกหนึ่งสามารถรองรับได้ ผู้โจมตีอาจสแปมเครือข่ายด้วยธุรกรรมที่ซับซ้อนซึ่งใช้เวลาประมวลผลนานมากจนทำให้ทั้งระบบหยุดชะงักได้

เลเยอร์ 2 และคอขวดด้านการขยายตัวอันเนื่องมาจากความพร้อมใช้งานของข้อมูล (Data Availability)

เพื่อแก้ปัญหาข้อจำกัดของเลเยอร์ 1 อุตสาหกรรมจึงได้คิดค้นโซลูชันเลเยอร์ 2 ขึ้นมา โดยเฉพาะอย่างยิ่ง "โรลอัป" (rollups) โปรโตคอลเหล่านี้จะดำเนินการธุรกรรมแบบนอกเชน (off-chain) รวบรวมธุรกรรมเหล่านั้นเข้าไว้ในบล็อก จากนั้นจึงส่งข้อมูลเวอร์ชันที่ถูกบีบอัดหรือหลักฐานทางวิทยาการรหัสลับ (cryptographic proof) กลับไปยังเชนหลัก (เลเยอร์ 1) แม้จะดูเหมือนเป็นแนวคิดที่สมบูรณ์แบบ แต่ก็นำมาซึ่งภาระเพิ่มเติม นั่นคือ DA (Data Availability หรือความพร้อมใช้งานของข้อมูล) แม้ว่าการประมวลผลจะเกิดขึ้นนอกเชน แต่ข้อมูลที่เพียงพอสำหรับการ "สร้างสถานะของโรลอัปขึ้นใหม่" (rebuild rollup state) จะต้องปรากฏอยู่บนเชน เพื่อให้ทุกคนสามารถตรวจสอบได้

พื้นที่บล็อกบนเชนหลักนั้นมีค่าและมีอยู่อย่างจำกัด ตัวอย่างเช่น การส่งข้อมูล calldata จำนวนมหาศาลไปยัง Ethereum จะมีค่าใช้จ่ายที่สูงมาก นี่คือเหตุผลที่เราเห็นข้อเสนออย่าง EIP-4844 (Proto-Danksharding) ที่นำเสนอแนวคิดเรื่อง "blobs" ซึ่งเป็นประเภทการจัดเก็บข้อมูลแบบใหม่ที่มีราคาถูกกว่าและเป็นข้อมูลชั่วคราว (ephemeral) โดยถูกออกแบบมาเพื่อโรลอัปโดยเฉพาะ อย่างไรก็ตาม แม้จะมี blobs แต่ก็ยังมีขีดจำกัดของปริมาณข้อมูลที่สามารถส่งผ่านเครือข่ายได้โดยไม่ทำให้โหนดมีขนาดใหญ่เกินไป (bloated nodes) เมื่อเลเยอร์ DA เต็ม ค่าธรรมเนียมในการใช้งานเลเยอร์ 2 เหล่านั้นจะพุ่งสูงขึ้นอย่างมาก เนื่องจากโรลอัปต่างต้องแข่งขันกันเพื่อให้ได้พื้นที่ที่มีจำกัดในการส่งชุดข้อมูล (batches) ของตน สิ่งนี้ทำให้เกิดตลาดที่ราคาของธุรกรรมบน L2 ที่เคยถูก กลับต้องขึ้นอยู่กับความหนาแน่นของ L1 ที่มีราคาแพงโดยตรง มันคือการแลกเปลี่ยนกันระหว่างการรักษาความปลอดภัยและต้นทุนในการรักษาความปลอดภัย (การส่งข้อมูลไปยัง L1) กับการใช้งานจริง

ภาระจากประวัติศาสตร์: การขยายตัวของสถานะและการจัดเก็บข้อมูล

หนึ่งในปัญหาที่สำคัญที่สุด และมักถูกลืมไปพอๆ กัน คือสิ่งที่เรียกว่า "state bloat" หรือการบวมของสถานะข้อมูล

บล็อกเชนประกอบด้วยสำเนาที่เหมือนกันของทุกธุรกรรมที่เคยเกิดขึ้น เมื่อมีผู้ใช้งานในเครือข่ายมากขึ้น ประวัติเหล่านี้ก็ขยายตัวตามไปด้วย แต่มันไม่ใช่แค่เรื่องของประวัติเท่านั้น แต่มันคือ "สถานะ" (state) ซึ่งก็คือยอดเงินปัจจุบันของทุกบัญชีและการถือครองของทุกสัญญาอัจฉริยะ โหนดจำเป็นต้องสามารถตรวจสอบธุรกรรมได้เพื่อให้ทราบว่าสถานะปัจจุบันคืออะไร โดยต้องมั่นใจได้ว่า Alice มีโทเคน 10 เหรียญที่เธอต้องการส่งให้ Bob จริงๆ ยิ่งสถานะมีขนาดใหญ่ขึ้นเท่าใด ก็ยิ่งต้องใช้ RAM และพื้นที่จัดเก็บข้อมูลแบบ SSD มากขึ้นเพื่อให้เข้าถึงข้อมูลได้อย่างรวดเร็ว

หากสถานะมีขนาดใหญ่เกินกว่าที่ฮาร์ดแวร์ระดับผู้บริโภคทั่วไปจะรับไหว จะมีเพียงศูนย์ข้อมูล (datacenter) ขนาดใหญ่เท่านั้นที่สามารถรันโหนดได้ ซึ่งจะส่งผลเสียต่อความเป็นระบบกระจายศูนย์ (decentralization) การเพิ่มประสิทธิภาพในส่วนนี้จึงเป็นเรื่องที่ยากอย่างยิ่ง คุณไม่สามารถแค่ตัดข้อมูลเก่าทิ้ง (prune) ได้ เพราะมันต้องพึ่งพาประวัติทั้งหมดของเชนย้อนกลับไปจนถึงบล็อกเริ่มต้น (Genesis block) เหล่านักพัฒนาจึงกำลังทดลองใช้ "stateless clients" และ "state expiry" โดยการบันทึกข้อมูลเก่าและใช้เพียงหลักฐานยืนยันข้อมูลเหล่านั้นแทน แต่นี่เป็นโซลูชันการเข้ารหัสลับที่ซับซ้อนและล้ำสมัยซึ่งต้องใช้เวลาหลายปีกว่าจะนำมาใช้งานได้อย่างปลอดภัย เรากำลังต่อสู้กับการสะสมข้อมูลที่มากเกินไปอยู่ตลอดเวลา

ทุกสัญญาที่คุณปรับใช้ (deploy) และทุกโทเคนที่คุณสร้าง (mint) คือภาระที่โหนดต้องแบกรับไว้ตลอดกาล การใช้ทรัพยากรเช่นนี้คือเหตุผลที่บางเครือข่ายนำโมเดลทรัพยากรอย่าง Energy และ Bandwidth มาใช้ ผู้ใช้อาจจำเป็นต้องเติมคะแนน Energy เพื่อโต้ตอบกับสัญญาอัจฉริยะโดยไม่ต้องเสียโทเคน หรือถือครอง TRON Energy เพื่อให้ประมวลผลธุรกรรมได้รวดเร็วยิ่งขึ้น โมเดลเหล่านี้คือความพยายามในการคิดค่าธรรมเนียมให้เหมาะสมกับภาระที่เกิดขึ้นในเครือข่าย กล่าวคือ ผู้ที่ใช้งานสถานะจะต้องจ่ายเพื่อสนับสนุนระบบนั้นเอง หากไม่มีกลไกดังกล่าว "โศกนาฏกรรมของส่วนรวม" (tragedy of the commons) จะส่งผลให้บล็อกเชนเต็มไปด้วยข้อมูลจนไม่สามารถใช้งานได้

ฉันทามติและภาระที่เกิดขึ้นผ่านกลไกฉันทามติ

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

ผู้ตรวจสอบธุรกรรม (Validators) จำเป็นต้องแลกเปลี่ยนชุดข้อความกันอย่างต่อเนื่องเพื่อยืนยันว่าบล็อกต่างๆ ควรได้รับการพิจารณาว่าถูกต้องอย่างไร เมื่อจำนวนผู้ตรวจสอบเพิ่มขึ้นเพื่อขยายการกระจายศูนย์ จำนวนข้อความก็จะเพิ่มขึ้นตามไปด้วย (ในอัตราก้าวกระโดด) "การสื่อสารที่หนาแน่น" (chatter) นี้สามารถทำให้เครือข่ายทำงานหนักเกินไป การเพิ่มประสิทธิภาพอัลกอริทึมฉันทามติเพื่อให้สามารถรองรับผู้ตรวจสอบหลายพันรายได้โดยไม่ทำให้ความเร็วในการทำธุรกรรมลดลงจนช้าอย่างยิ่งนั้นถือเป็นงานที่ยากลำบากอย่างมาก มีการใช้คณิตศาสตร์ขั้นสูงและเทคนิค "การรวมลายเซ็น" (signature aggregation) (คล้ายกับลายเซ็น BLS) เพื่อย่อคะแนนเสียงหลายพันเสียงให้เหลือเพียงข้อมูลชิ้นเล็กๆ เพียงชิ้นเดียว นอกจากนี้ "ความสิ้นสุด" (finality) ของธุรกรรม หรือการรับประกันว่าธุรกรรมนั้นไม่สามารถย้อนกลับได้ มักจะมีลักษณะเป็นเชิงความน่าจะเป็น (probabilistic)

ในหลายเครือข่าย คุณต้องรอให้ผ่านไปหลายบล็อกก่อนจึงจะมั่นใจได้ ความล่าช้านี้เกิดจากการบรรลุข้อตกลงร่วมกัน (convergence) ของฉันทามติในเครือข่าย นี่คือคุณลักษณะด้านความปลอดภัย ไม่ใช่ข้อผิดพลาด แต่มันอาจดูเหมือนเป็นคอขวดสำหรับผู้ใช้ที่รอการยืนยัน นอกจากนี้ ปัญหา "Nothing at Stake" ในการออกแบบ PoS ยุคแรกๆ ทำให้จำเป็นต้องมีกลไก "slashing" ที่ซับซ้อนเพื่อลงโทษพฤติกรรมที่ไม่เหมาะสม ซึ่งส่งผลให้มีตรรกะเพิ่มเติมที่ต้องประมวลผลในทุกๆ บล็อก" อีกหนึ่งคอขวดที่ซ่อนอยู่คือ “ความหลากหลายของไคลเอนต์” (client diversity) เมื่อทุกคนรันซอฟต์แวร์ไคลเอนต์ตัวเดียวกัน (เช่น Geth) บั๊กเพียงจุดเดียวก็สามารถทำให้เครือข่ายล่มได้ทั้งระบบ การส่งเสริมความหลากหลายของไคลเอนต์ในระบบนิเวศจึงเป็นสิ่งสำคัญเพื่อสร้างความยืดหยุ่น (resilience) แต่สิ่งนี้ก็นำมาซึ่งภาระงานในการพัฒนา (development overhead) ที่เพิ่มขึ้นอย่างมาก

ภาษีแฝง: MEV และคอขวดในการประมวลผล

เวอร์ชวลแมชชีน (VM): นี่คือสภาพแวดล้อมในการประมวลผลสำหรับสมาร์ทคอนแทรค (smart contracts) โดย Ethereum Virtual Machine (EVM) คือมาตรฐานหลัก แต่เดิมทีมันไม่ได้ถูกออกแบบมาเพื่อการทำงานแบบขนานที่มีปริมาณงานสูง (high-throughput parallel operations) มันจะรับธุรกรรมทีละรายการและประมวลผลตามลำดับที่ได้รับ หากมีธุรกรรมหนึ่งที่ซับซ้อนมากและใช้เวลาคำนวณนาน ธุรกรรมอื่น ๆ ทั้งหมดก็ต้องรอคิว ซึ่งเปรียบได้กับแถวชำระเงินเพียงแถวเดียวในซูเปอร์มาร์เก็ต บล็อกเชนสมัยใหม่กำลังพยายามบรรลุ “การประมวลผลแบบขนาน” (parallel execution) ซึ่งธุรกรรมที่ไม่ขัดแย้งกัน (เช่น อลิซโอนเงินให้บ็อบ และชาร์ลีโอนเงินให้เดฟ) สามารถประมวลผลพร้อมกันได้โดยใช้คอร์ของ CPU ที่ต่างกัน แต่นั่นก็เป็นเรื่องที่พูดง่ายกว่าทำ เพราะการระบุว่าธุรกรรมใดขัดแย้งกันในแบบเรียลไทม์นั้นถือเป็นปัญหาทางวิทยาการคอมพิวเตอร์ที่ท้าทายอย่างยิ่ง

และนอกเหนือจากความเร็วในการประมวลผลแล้ว ยังมีคอขวดของ MEV อีกด้วย เนื่องจากธุรกรรมส่วนใหญ่สามารถมองเห็นได้ทันทีที่ถูกส่งไปยังเมมพูล (mempool) บอทที่ล้ำสมัยจึงสามารถทำ front-run หรือ sandwich ธุรกรรมของผู้ใช้เพื่อแสวงหาผลกำไรได้ สิ่งนี้เปรียบเสมือนภาษีแฝงสำหรับผู้ใช้ ซึ่งนำไปสู่อัตราแลกเปลี่ยนที่แย่ลงและธุรกรรมที่ล้มเหลว นอกจากนี้ยังทำให้เครือข่ายเต็มไปด้วยสแปมจากบอทที่ต่อสู้กันเอง การแก้ปัญหา MEV ถือเป็นหนึ่งในปัญหาที่ท้าทายและสำคัญที่สุดในการเพิ่มประสิทธิภาพของบล็อกเชน

แนวทางต่างๆ เช่น “proposer-builder separation” (การแยกผู้เสนอและผู้สร้างบล็อก) พยายามจัดการกับปัจจัยกำหนดนี้โดยนัย แต่ก็ยังคงเป็นความไม่มีประสิทธิภาพที่ดำเนินอยู่ ซึ่งนำไปสู่ประสบการณ์การใช้งานที่ย่ำแย่

โลกที่แตกแยก: ความท้าทายด้านการทำงานร่วมกันระหว่างเครือข่าย

ด้วยการเปลี่ยนผ่านสู่โลกแบบมัลติเชน (multi-chain) คอขวดใหม่จึงเกิดขึ้น นั่นคือความสามารถในการทำงานร่วมกันระหว่างเครือข่าย (interoperability) เราได้สร้างเกาะแห่งมูลค่าเล็กๆ ขึ้นมามากมาย การโอนสินทรัพย์จาก Ethereum ไปยัง Solana หรือจาก Bitcoin ไปยังเครือข่าย Layer 2 จำเป็นต้องใช้ “สะพานเชื่อม” (bridges) สะพานเหล่านี้คือจุดอ่อนในระบบนิเวศ ซึ่งเสี่ยงต่อการถูกแฮ็กและการแสวงหาผลประโยชน์ (exploits) การ “wrapping” โทเค็นเป็นอีกชั้นของความซับซ้อนและความเสี่ยงที่อาจเกิดขึ้น คอขวดในเรื่องนี้คือการขาดโปรโตคอลการสื่อสารที่เป็นสากล บล็อกเชนแต่ละแห่งพูดคนละภาษา และมีกลไกฉันทามติ (consensus) เกี่ยวกับเวลาและความสมบูรณ์ของธุรกรรม (finality) ที่แตกต่างกัน

การสร้างสะพานแบบ “trustless” (ไม่ต้องอาศัยความไว้วางใจ) ซึ่งไม่ขึ้นอยู่กับผู้ดูแลทรัพย์สินแบบรวมศูนย์ (centralized custodian) นั้นเป็นเรื่องที่ยากมากในทางคณิตศาสตร์ มันต้องการให้เชนใดเชนหนึ่งในสองเชนนั้นรัน “light client” (เช่น การตรวจสอบส่วนหัวของบล็อกและหลักฐานยืนยัน) สิ่งนี้ยังต้องใช้ทรัพยากรการประมวลผลและข้อมูลอย่างมหาศาล นอกเหนือจากความยุ่งยากในการเคลื่อนย้ายสภาพคล่องข้ามเชนแล้ว สิ่งนี้ยังทำให้ตลาดแตกแยกและขาดประสิทธิภาพ ผู้ใช้ติดอยู่บนเชนเดียวโดยไม่มีวิธีง่ายๆ ในการเติมพลังงาน TRON และเคลื่อนย้ายสินทรัพย์ไปยังจุดที่ให้ผลตอบแทน (yield) ดีที่สุด เว้นแต่พวกเขาจะฝ่าฟันเครือข่ายโปรโตคอลที่ซับซ้อนและเสี่ยงอันตราย ยิ่งไปกว่านั้น “atomic composability” (ความสามารถในการประกอบกันได้แบบเบ็ดเสร็จ) ซึ่งเป็นแนวคิดที่ว่าเราสามารถทำธุรกรรมกับหลายโปรโตคอลได้พร้อมกันในธุรกรรมเดียว จะสูญเสียไปเมื่อมีการเคลื่อนย้ายข้ามเชน คุณไม่สามารถกู้ยืมแบบ flash loan บนเชน A เพื่อไปทำกำไรจากส่วนต่าง (arbitrage) ของสิ่งที่ผิดปกติบนเชน B ได้ โดยไม่มีความเสี่ยงและความล่าช้าที่สำคัญ

ปัจจัยด้านมนุษย์: การกำกับดูแลและการอัปเกรด

ท้ายที่สุด คอขวดที่น่าหงุดหงิดที่สุดอาจเป็นเรื่องของมนุษย์ นั่นคือ การกำกับดูแล (governance) บล็อกเชนคือซอฟต์แวร์ และซอฟต์แวร์จำเป็นต้องได้รับการอัปเดต แต่ในเครือข่ายแบบกระจายศูนย์ ใครจะเป็นผู้ตัดสินใจว่าการอัปเกรดจะเกิดขึ้นเมื่อใดและอย่างไร? การกำหนดเวลาสำหรับ "ฮาร์ดฟอร์ก" (hard fork) ซึ่งเป็นการอัปเกรดที่ไม่สามารถทำงานร่วมกับเวอร์ชันเก่าได้ (not backward compatible) จำเป็นต้องอาศัยความเห็นพ้องต้องกันระหว่างเหล่านักพัฒนา ผู้ดำเนินการโหนดในเครือข่าย และนักขุด/ผู้ตรวจสอบธุรกรรม ตลอดจนฉันทามติจากชุมชนโดยรวม หากมีความเห็นไม่ตรงกัน เครือข่ายบล็อกเชนอาจเปลี่ยนทิศทางได้ ดังเช่นที่เคยเกิดขึ้นกับ Ethereum ซึ่งต่อมาได้มีการแยกเชนออกเป็นสองเหรียญในปัจจุบัน ได้แก่ Ethereum และ Ethereum Classic.

ความต้องการข้อตกลงทางสังคมนี้ไม่เพียงแต่เป็นอุปสรรคต่อการเปลี่ยนแปลงเท่านั้น แต่ยังรวมถึงนวัตกรรมด้วย บริษัทเทคโนโลยีที่ใช้แพลตฟอร์มสามารถอัปเดตเซิร์ฟเวอร์ของตนได้ภายในไม่กี่นาที หากบล็อกเชนจำเป็นต้องปฏิบัติตามฟังก์ชัน f ใดๆ แม้จะเป็นฟังก์ชันที่เล็กน้อยที่สุด ก็เป็นเรื่องที่เป็นไปไม่ได้ที่เชนจะรับเอาการปรับปรุงใหม่ๆ มาใช้ได้อย่างรวดเร็ว "การลดบทบาทการกำกับดูแล" (governance minimization) มักเป็นเป้าหมายหลัก แต่ในช่วงเริ่มต้น การกำกับดูแลเชิงรุกถือเป็นสิ่งจำเป็นในการแก้ไขข้อผิดพลาดและพัฒนาโปรโตคอล การแลกเปลี่ยนระหว่างมิติของ "การก้าวให้ไวและยอมรับความผิดพลาด" (move fast and break things) กับ "ความเสถียรและความไม่สามารถเปลี่ยนแปลงได้" (stability, immutability) มักเป็นบ่อเกิดของความขัดแย้งเสมอ สิ่งนี้เองที่สามารถเปลี่ยนการเพิ่มประสิทธิภาพที่สำคัญที่สุดบางอย่าง เช่น การเพิ่มขนาดบล็อก หรือแม้แต่การเปลี่ยนกลไกค่าธรรมเนียม ให้กลายเป็นสมรภูมิทางการเมืองที่ทำให้ความคืบหน้าล่าช้าไปหลายปี

บทสรุป

คอขวดของบล็อกเชน ไม่ว่าจะเป็นความสามารถในการขยายตัว (scalability), ความพร้อมใช้งานของข้อมูล (data availability), สภาวะข้อมูลบวม (state bloat), ภาระของฉันทามติ (consensus overhead), ความเร็วในการประมวลผล (execution speed), MEV, การทำงานร่วมกันระหว่างเครือข่าย (interoperability) และการกำกับดูแล (governance) ไม่ใช่ข้อจำกัดที่เกิดขึ้นอย่างไม่มีที่มาที่ไป แต่เป็นผลพลอยได้จากความทะเยอทะยานที่จะสร้างคอมพิวเตอร์ระดับโลกที่กระจายศูนย์ ปลอดภัย และไม่ต้องอาศัยความเชื่อใจ (trustless) ทุกการเพิ่มประสิทธิภาพคือการแลกเปลี่ยน การเพิ่มขนาดบล็อกส่งผลเสียต่อความเป็นกระจายศูนย์ การทำ Sharding ทำให้ความปลอดภัยกลายเป็นความท้าทายที่ยากขึ้นมาก และการประมวลผลแบบขนาน (Parallel execution) ก็มีความเสี่ยงที่จะทำให้ข้อมูลเกิดความไม่สอดคล้องกัน (state inconsistency) ดังนั้น จึงเป็นเรื่องที่น่าทึ่งมากที่ได้เห็นความก้าวหน้าในระดับปี 2026 ของ Layer 2 rollups, การสุ่มตัวอย่างความพร้อมใช้งานของข้อมูล (data availability sampling) และการผสมผสานข้อมูล รวมถึง zero-knowledge snarks ไม่ต้องพูดถึงการพิสูจน์ (proofs) ในภาพรวม ที่กลายเป็นความจริงขึ้นมาได้ในปัจจุบัน จากฝีมือของผู้คนที่คิด "นอกกรอบ" มาตลอดหลายปีที่ผ่านมา

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

สำหรับผู้ที่ต้องรับมือกับความซับซ้อนในการจัดหาทรัพยากรในเครือข่าย Tron พวกเขาสามารถใช้เครื่องมืออย่าง Netts Energy Charge Bot ได้ โดยผู้ให้บริการ (Chargers) จะได้รับ Energy สำหรับการโอนและปล่อยเช่า ($) ให้กับผู้ใช้ เมื่อมีการโอน Tether ผ่าน Charge_bot (Telegram) ซึ่งวิธีนี้จะช่วยลดค่าธรรมเนียมในการโอน USDT ลงได้ ผู้ใช้เพียงแค่เลือกวอลเล็ตและฝากเงินเข้าไปเป็นเหรียญ TRX จากนั้นก็สามารถใช้สกุลเงินกลางเพื่อเติม Energy สำหรับใช้งานหนึ่งชั่วโมง เพื่อที่คุณจะได้ไม่ต้องเผา (burn) เหรียญ TRX จำนวนมากในการโอน สิ่งนี้ช่วยให้กระบวนการง่ายขึ้นเล็กน้อย เพียงแค่เลือกวอลเล็ต เติมพลังงาน และทำการโอน โดยบอทอาจช่วยคำนวณทรัพยากรที่ต้องใช้โดยประมาณให้ด้วย ถือเป็นเครื่องมือเล็กๆ แต่มีค่าในการยกระดับประสบการณ์ผู้ใช้ (UX) ในสภาพแวดล้อมที่ทรัพยากรทุกส่วนมีความสำคัญ!