ยังมองไม่ออกเลยว่า LibraBFT จะสเกลเพื่อรับ Transaction per second (tps) เพิ่มได้ยังไง #GeekAlert #ไม่ใช้ภาษามนุษย์นะโพสต์นี้ #เตือนละนะ
.
LibraBFT ถึงจะเป็น Consensus Protocol กลุ่ม BFT ที่พัฒนาขึ้นมาจากตัวแรก ๆ เยอะมาก แต่ก็ยังไม่ใช่ Perfect Solution อยู่ดี (อย่างน้อยก็ใน Approach ปัจจุบัน)
.
BFT ตัวที่โบราณหน่อยแต่ดังก็คือ PBFT (Practical Byzantine Fault Tolerance) เพราะมันง่ายสุด คือให้ทุก Validator คุยกันเลย ทำให้มีข้อความที่ต้องส่งถึงกันถึง n^2 ถึง n^4 แล้วแต่จะออกแบบ (n คือจำนวน Validator) สุดท้าย Big O เลยล่อไป O(n^3) โดยเฉลี่ย ทำให้เวลามี Validator เยอะ ๆ มันเลยอืดลงเรื่อย ๆ ไม่สามารถสเกลได้
.
ในคำว่า Scalability ของโลก Blockchain ไม่เหมือนกับ Scalability ในโลกของ Centralized Server ปกติเท่าไหร่ คือพวก Centralized Server เนี่ยยิ่งเพิ่มเครื่องจะยิ่งรับ Concurrency ได้มากขึ้น แต่สำหรับ Decentralized เนี่ย มันจะยิ่งหน่วงลงเรื่อย ๆ เพราะเครื่องต้องสื่อสารกันมากขึ้น*
.
(*แล้วแต่ออกแบบ แต่ส่วนใหญ่เป็นแบบนั้น หรือถ้าไม่ใช่ก็จะแลกมาด้วยอะไรบางอย่างเสมอ)
.
BFT ก็พัฒนามาเรื่อย ๆ เพื่อลด Big O ลง อย่าง Tendermint ก็ BFT ที่ O(n^2) และล่าสุด vmware ก็นำเสนอ BFT ที่ประสิทธิภาพดีที่สุดอย่าง Hot-Stuff ออกมา Big O อยู่ที่ O(n) เท่านั้น แปลว่าการเพิ่มเครื่องไม่ได้ทำให้หน่วงขึ้นมากเหมือนอันเก่า ๆ ทุกอย่างเป็น Linear
.
เบื้องหลังของ Hot-Stuff คือเป็น BFT แบบ "Leader-based" ก็คือแทนที่จะใช้วิธีคุยกันด้วยทุก Validator แบบ PBFT ก็เปลี่ยนเป็นให้ทุก Validator มาคุยกับ Leader ซึ่งมีตัวเดียวแทน ข้อความเลยส่งกันด้วย O(n) เท่านั้น
.
และความหมายใน Paper ที่บอกว่า LibraBFT สเกลได้ก็คือ "สเกลจำนวน Validator ได้" ไม่ได้แปลว่าจะเพิ่มจำนวน Transaction per second ได้แต่อย่างใด
.
และพอมองไปยาว ๆ ก็ยังไม่เห็นว่าการโตของจำนวน Validator จะทำให้ระบบมันทำงานได้เยอะขึ้นเลย มีแต่จะช้าลง ๆ ตะหาก
.
ข้อได้เปรียบของ LibraBFT (Hot-Stuff) คือ คิดว่าน่าจะรับได้หลายพัน tps ตั้งแต่แรกแหละ แค่เค้าลิมิตไว้ที่ 1,000 tps ก่อนด้วยเหตุผลหลายประการ แต่สุดท้ายถ้าปลดล็อคมันก็จะมีเพดานของมันอยู่ดี
.
และสเปคเครื่องที่จะรัน Validator Node ได้ก็ถือว่าโหดเหมือนกัน เพราะยิ่งต้องรับ tps ได้มากขึ้น พวก CPU, RAM ก็จะต้องยิ่งสูงขึ้นเร็วขึ้น Harddisk ก็จะยิ่งบวมเร็วขึ้น แปลว่าค่า Maintainance ของ Validator Node ก็จะสูงขึ้นเรื่อย ๆ ด้วย ไม่รู้จะถึงจุดที่คนรู้สึกเสียใจที่ตั้ง Validator Node มั้ย
.
เท่าที่พิจารณาดู ช่องทางที่เหมาะสมกับการสเกล tps ก็มีอยู่สอง Approach คือ
.
1) Sharding
.
2) Off-chain Solution
.
ซึ่งก็ยังไม่มีข้อมูลจากฝั่งไหนเลยว่าจะทำมั้ย แต่ก็มีโอกาสที่ Calibra จะทำ ในกรณีนั้นก็จะไม่มีปัญหาเรื่องสเกลละ ตัว Libra ก็คงให้อยู่ 1000 tps ต่อไปได้อีกนาน
.
ไว้รอดูกันต่อไปจ่ะ