Avalanche Consensus กับความก้าวหน้าที่ยิ่งใหญ่ที่สุด นับตั้งแต่ที่มี Nakamoto เกิดขึ้นมา
ต้นฉบับโดย Seq: Avalanche Consensus, The Biggest Breakthrough since Nakamoto | by Seq | Avalanche Hub | Medium
Consensus หมายถึงฉันทามติ เป็นกลไกที่ทำให้เครือข่าย (network) บล็อคเชนนั้นเห็นพ้อง รับรองความถูกต้องของข้อมูลธุรกรรมร่วมกัน เปรียบเสมือนการร่วมกันลงคะแนนเสียงของกลุ่มคนที่เป็นอิสระต่อกัน (เรามักเรียกว่า Validators และจำนวนของ Validator อาจเรียกว่า node เช่นมี Validator จำนวน 10 nodes) ซึ่งเป็นการตัดสินใจด้วยข้อกำหนดที่มีร่วมกัน เพื่อให้แน่ใจว่าข้อมูลใน network นั้นได้ประสานเป็นชุดเดียวกัน (synchronized) โดยเราเรียกสิ่งนี้ว่า “State” หรือสถานะ ซึ่งถ้าไม่มี Consensus ก็จะเป็นไปไม่ได้ที่เราจะมั่นใจใน state ของ Validator เพียง 1 node ที่ทำการตัดสินความถูกต้องของข้อมูล หรือพูดอีกอย่างว่าเราจำเป็นต้องมี Validators เพิ่มเติมมากกว่านี้ เพื่อออกความเห็นไปในทิศทางเดียวกัน ใน state เดียวกัน
ทั่วไปแล้ว มักมีการเข้าใจผิดเกี่ยวกับ Proof-of-Work (PoW) และ Proof-of-Stake (PoS) ว่าเป็น Consensus protocols ชนิดหนึ่ง แต่ที่จริงแล้ว มันเป็นกลไกอย่างหนึ่งเรียกว่า Sybil Control Mechanism โดยกลไก PoS นั้น ไม่ได้ทำให้ Consensus บรรลุผลลัพธ์ แต่มันจะต้องทำงานร่วมกับ Protocol อย่างเช่น PBFT, Tendermint/Cosmo หรือ Avalanche เพื่อให้เกิดกระบวนการการตัดสิน และ PoW ก็ไม่ใช่ Consensus โดยตัวมันเองเช่นกัน ซึ่ง BTC/BCH นั้นใช้หลักเกณฑ์ในการตัดสิน รับรองความถูกต้อง โดยการเลือก Chain ที่ข้อมูลมากที่สุด/ยาวที่สุด เพื่อที่จะเสร็จสิ้นกระบวนการใน Consensus
และเป็นประวัติศาสตร์ยาวนานกว่า 45 ปี เลยทีเดียว ของการมีระบบกระจายศูนย์ (distributed system) แต่มีเพียงแค่ 3 ระบบเท่านั้น ที่ใช้แก้ปัญหาใน consensus ได้ นั่นคือ Classical, Nakamoto และ Avalanche
Classical Consensus Protocols
Protocols นั้นเป็นช่องทางที่คอมพิวเตอร์ใช้สื่อสารแลกเปลี่ยนข้อมูลกัน
Classical consensus protocol อย่างเช่น Practical Byzantine Fault Tolerance (PBFT), HotStaff และ Tendermint/Cosmos พวกนี้มีพื้นฐานเป็นการร่วมกันตัดสินรับรองความถูกต้องแบบทั่วถึงกันทั้งหมด (all-to-all voting) ซึ่ง mechanism หรือกลไกนี้ เกิดขึ้นมาตั้งแต่ปี 1980s ทั่วไปแล้วจะมีการออกแบบกลไก ให้มีผู้นำ (leader) เป็นผู้เริ่มต้นกระบวนการการตัดสิน ซึ่งจะสื่อสารกับ nodes อื่น ๆ อย่างเป็นชุดลำดับ ในแต่ละรอบ (series of rounds) และก็เป็นแบบ all-to-all เพื่อให้แน่ใจว่า nodes ทั้งหมดนั้นมีความน่าเชื่อถือของการตัดสินรับรองความถูกต้อง และธุรกรรมนั้นจะเสร็จสิ้นทันที หลังจาก node ที่เป็น leader ได้รับการตอบกลับจาก nodes จำนวนหนึ่ง ที่เป็นส่วนหนึ่งในระบบ
การสื่อการกันแบบ all to all messages สำหรับการตัดสินในการทำธุรกรรม มีหลักการ คือแต่ละ node ต้องได้รับการสื่อสารจาก nodes อื่น ๆ ทั้งหมด ที่มีอยู่ในระบบ และทุก ๆ node ต่างก็จำเป็นต้องได้รับรู้ข้อมูลซึ่งกันและกัน เราก็จะได้จำนวนครั้งของการสื่อสาร เป็นจำนวนยกกำลังสองของจำนวน nodes ที่มีในระบบ ถ้าคุณต้องการรวมข้อมูลทั้งหมดจากคนจำนวน n คน และให้มันเป็นชุดเดียวกันกับทุก ๆ n คนนี้ ท้ายที่สุดแล้วคุณต้องรวบรวมข้อมูลเป็นจำนวน n ชุด และคนที่มีอยู่จำนวน n คน ก็ต้องรวบรวมข้อมูลจำนวน n ชุดด้วยเช่นกัน
ขยายความเพิ่มอีกเล็กน้อย เช่น ในคณะกรรมการหนึ่งมีอยู่ 3 คน คือ A , B และ C ต้องการสื่อสารเพื่อออกความเห็น ตัดสินข้อมูลการทำธุรกรรมชุดหนึ่ง A จะต้องสื่อสารและรวบรวมข้อมูลจาก B และ C โดยจะได้ข้อมูลรวมเป็น 3 ชุดข้อมูล (รวมของตัวเอง) และ B กับ C ต่างก็จะต้องทำเช่นเดียวกันกับ A ทำให้นับจำนวนครั้งของการสื่อสาร (ชุดข้อมูล) ได้เป็น 3x3 หรือ 3² = 9 ครั้ง และนี่เป็นการตัดสินเพียงแค่หนึ่งรอบ ของสมาชิกที่มีอยู่เพียง 3 คน
ซึ่งระยะเวลาที่ต้องใช้เพื่อการสื่อสารกันของ nodes (communication overhead) ด้วยวิธีการแบบ all-to-all จะมีค่าเป็นจำนวน nodes ยกกำลังสอง ถ้ามี 10 nodes ก็จะนับได้ว่ามีการสื่อสารกัน 100 ครั้ง ถ้า 100 nodes คิดเป็น 10,000 ครั้ง ถ้ามี 2,000 nodes แต่ละรอบก็จะต้องการสื่อสารกัน 4,000,000 ครั้ง และถ้ารอบไหน Leader สื่อสารพลาด การสื่อสารก็จะเพิ่มเป็น n³ ครั้ง มากไปกว่านั้น ระบบนี้ต้องการความแม่นยำของข้อมูลจากสมาชิกทั้งหมดใน consensus ความผิดพลาดใด ๆ ของสมาชิกในระบบ หรือมุมมองที่ต่างกันภายในระบบ จะส่งผลให้เกิดปัญหาด้านความปลอดภัย หากว่ามีการโจมตี และเข้าควบคุม nodes ได้เป็นจำนวน 1/3 + 1 ของ network ก็จะเป็นการันตีว่าสามารถทำให้เกิดการ double-spend ได้ (การที่สามารถใช้จ่าย หรือโอนเงินได้มากกว่าที่ตัวเองมีอยู่จริง)
Classical protocol ที่รองรับการใช้งาน (scale) ได้มากที่สุด คือ HotStaff ซึ่ง Facebook Libra ได้ใช้งานอยู่ (ออกแบบโดย Ted Yin ปัจจุบันทำงานร่วมกับ Avalanche protocol) โดยระบบนี้สามารถรองรับได้ประมาณ 100 Validators เท่านั้นถ้ามากกว่านี้จะทำให้ประสิทธิภาพลดลง ในขณะที่โปรเจกต์อื่น ๆ อ้างว่าใช้ Classical protocol แต่สามารถรองรับได้เป็นพัน nodes ระบบนี้จะทำการสุ่มเลือก nodes เพียงจำนวนเล็กน้อย (sub-committee) เพื่อมาทำกระบวนการใน consensus และบันทึกผลลงในแต่ละ block ส่วน nodes ที่เหลือจะไม่ได้เข้ามามีส่วนร่วมใน Consensus ค่าของการระเมิดด้านความปลอดภัยในระบบแบบนี้จะน้อย ตราบใดที่ค่าของการคอรัปชันจาก sub-committee นั้นมีน้อยด้วยเช่นกัน ซึ่งอาจมีค่าน้อยมาก ๆ (หมายถึงว่าจะมีความปลอดภัยหากใช้งานให้เหมาะสม)
หมายเหตุ: ในแต่ละ consensus นั้น nodes ก็คือ committee ซึ่งก็อาจจะมีการแบ่ง nodes ออกไปเป็นหลาย ๆ committees ก็ได้ และหรืออาจจะแบ่งย่อยลงไปเป็นหลาย ๆ sub-committees เพื่อแบ่งหน้าที่การทำงาน ทั้งนี้ขึ้นอยู่กับหลักการของแต่ละ consensus
ด้วยการรองรับจำนวน nodes ที่มีอยู่อย่างจำกัด และจะยิ่งเป็นจุดอ่อนของระบบ เพราะจำเป็นต้องมีการรักษาความถูกต้องของการเป็นสมาชิก (ถ้ายิ่งเพิ่ม nodes ก็จะยิ่งแย่) จึงทำให้ไม่ยั่งยืน ไม่เหมาะกับการไปใช้กับระบบใหญ่ ๆ หรือระบบแบบเปิด และเป็นแบบ Permission-less (ที่เป็นสาธารณะ ไม่ต้องขออนุญาตเพื่อใช้งาน) ซึ่งระบบที่ว่านี้ nodes อาจจะเข้าร่วม หรือจะถอนตัวเมื่อไหร้ก็ได้
Nakamoto consensus protocols
ถือว่าเป็นครั้งแรกของการเปลี่ยนผ่านครั้งสำคัญของ consensus protocol ที่เคยมีมา น้่นคือ Nakamoto consensus protocols ที่ซึ่งมีชื่อเสียงจากการมาของ Bitcoin แต่คราวนี้ไม่ได้มีวิธีการสื่อสารกันแบบ all-to-all และด้วยความเป็นระบบเปิด (permission-less) ใครที่จะมาทำ node สามารถเข้าร่วมเมื่อไหร่ก็ได้ ไม่เหมือนกับ Classical consensus protocols ที่ใช้หลักการความน่าจะเป็นเพื่อให้เกิดความปลอดภัย แทนที่จะใช้หลักการที่เป็นการการันตีความปลอดภัยสะเลย โดยการกำหนดค่า parameter ของ protocol ให้มีความน่าจะเป็นเพียงเล็กน้อยที่จะมีโอกาสเกิดการ double spend จึงทำให้ protocol นี้มีโครงสร้างระบบการเงินที่มีมูลค่าสูง
อย่างไรก็ตาม protocols เหล่านี้มีค่าใช้จ่ายสูง สิ้นเปลือง และมีประสิทธิภาพจำกัด ต้องใช้พลังงานมหาศาลในการคำนวณที่เปล่าประโยชน์ โดยงานวิจัยจาก The International Energy Agency ได้ประเมินไว้ว่าการขุดเหรียญสกุลดิจิตอลนั้นใช้พลังงานอย่างน้อย เท่ากับประเทศไอร์แลนด์ทั้งประเทศ ผลที่ตามมา คือระบบที่มีพื้นฐานจาก Nakamoto จะค่อย ๆ สูญเสียมูลค่าจาก ecosystems ไปสู่บริษัทผู้ผลิตไฟฟ้า เพราะต้องรักษาความปลอดภัยของระบบ Proof of Work นักขุดไม่สามารถที่จะทำการปิดเครื่องได้เลย (ต่อให้ไม่มีธุรกรรม ก็จะหยุดพักไม่ได้) นั่นจึงเป็นเหตุผลที่จะมีการใช้พลังงานอย่างไม่มีที่สิ้นสุด การขุดแต่ละ block นั้นถูกออกแบบให้มีความยาก จึงเป็นเหตุทำให้การปิดธุรกรรม (finalize) นั้นช้ามาก ใช้เวลา 1 ชั่วโมงในการปิดแต่ละธุรกรรมของ Bitcoin และความล่าช้านี้ (low latency) จะไม่พัฒนาไปอย่างที่เทคโนโลยีนั้นเป็น
Avalanche Consensus protocols
“มีเพียงแค่ 3 ครั้งเท่านั้น ในประวัติศาสตร์ 45 ปี ของของการมีระบบกระจายศูนย์ (distributed system) และเราได้มี Family ใหม่ ของ distributed system เกิดขึ้นมา นั่นคือ Avalanche ซึ่งเป็นความก้าวหน้าครั้งสำคัญ เหมือนกับตอนที่ได้มี Satoshi protocol เกิดขึ้นมา โดย Avalanche นั้นเป็นการรวมสิ่งที่ดีที่สุดของทั้ง Satoshi และ Classical เข้าด้วยกัน ในแบบที่ไม่เคยมีมาก่อน ที่ทำให้ใครก็ตามสามารถ integrate ตัวเองลงใน consensus layer ได้” — Emin Gün Sirer
Avalanche consensus protocols นั้นถือเป็นความก้าวหน้าครั้งสำคัญอีกขั้นของ consensus protocols ที่มีการรวมข้อดีของ Nakamoto consensus (มีความทนทาน, รองรับการใช้งานปริมาณมากได้, มีความไร้ตัวกลาง) และข้อดีทั้งหมดของ Classical consensus (มีความเร็ว, ปิดธุรกรรมได้ย่างรวดเร็ว, มีประสิทธิภาพการใช้พลังงาน) โดยในปี 2018 ได้มีการเผยแพร่เอกสารโดยกลุ่มของบุคคลนามว่า Team Rocket ซึ่งได้พิสูจน์ว่า Classical protocols มีความเป็นไปได้ และสามารถปรับปรุงให้มีประสิทธิภาพเพิ่มขึ้นได้อีกมาก
เช่นเดียวกับวิธีที่ Nakamoto ใช้ คือยอมให้มีโอกาสที่จะเกิดข้อผิดพลาดเล็กน้อย เพื่อแลกกับประสิทธิภาพที่ได้กลับคืนมา Avalanche ก็เช่นกัน ที่มีความเป็นไปได้ที่เล็กน้อยมาก ที่จะเกิดข้อผิดพลาด และการละเมิดความปลอดภัยบน Avalanche node นั้น มีน้อยกว่าเมื่อเทียบกับการที่เราจะเจอการชนกัน (collision: การค้นพบว่า การใส่ข้อมูลที่แตกต่างกันลงไป แต่แล้วมีการสร้าง hash ออกมาเป็นค่าเดียวกัน) ของ SHA-256 hash หรือจะอธิบายเป็นอีกมุมว่า มีความเป็นไปได้ ที่ในอีกหลายร้อยปีข้างหน้าที่จะมีดาวเคราะห์น้อยที่หมดอายุขัยพุ่งใส่โลก มากกว่าการที่จะตรวจพบเจอการชนกันของ SHA-256 ในอีกหลายพันปี ด้วย network computing ขนาด 1 quintillion hashes ต่อวินาที (1x10¹⁸ hashes/sec)
Avalanche protocols นั้นยังมีน้ำหนักเบา และยั่งยืน แตกต่างจาก Nakamoto protocols ซึ่ง Avalanche นั้นใช้พลังงานน้อยมาก และเมื่อไม่มีงานให้ประมวลผล ระบบก็จะรอ และจะเข้าโหมดใช้พลังงานน้อย (อาจจะแปลไทยว่าเป็นโหมดประหยัดพลังงาน) ถือเป็นการเปลี่ยนเกมส์อย่างแท้จริง การมี tps (การรองรับธุรกรรมต่อวินาที) ที่รวดเร็ว ขณะที่มีความล่าช้าในการตอบสนอง (latency) มีเพียงเล็กน้อย (ซึ่งเราอาจจะคุ้นเคยกับค่า ping) จำนวนข้อความที่ใช้สื่อสาร ที่แต่ละ nodes ต้องรับมือ ต่อการตัดสินใจ คิดเป็น O (k) (หมายถึงว่ามีค่าคงที่) และจะไม่เพิ่มขึ้นตามขนาดของ network ที่โตขึ้น ดังนั้นสามารถขยาย Validators ออกไปได้เป็นหลักล้าน ซึ่งทั้งหมดนั้นจะมีส่วนร่วมใน Consensus เพื่อก้าวไปสู่ decentralization ระดับโลกอย่างแท้จริง ให้ความเป็นบล็อคเชนแบบสาธารณะ (permission-less) ส่งเสริมให้เกิดการใช้งาน blockchain ไปอย่างแพร่หลาย
Protocols ใน Avalanche family นั้นมีความเร็วสูงมาก สามารถปิดธุกรรมที่ย้อนกลับไม่ได้ภายใน 2 วินาที (ส่วนมากจะเกิดขึ้นน้อยกว่า 1 วินาที) ซึ่งเร็วกว่าการปิดธุรกรรมจากบัตรเครดิตทั่ว ๆ ไป สามารถรองรับการทำธุรกรรมได้หลายธุรกรรม/วินาที (TPS: Transaction per second) เร็วกว่า Visa ที่รองรับปริมาณข้อมูลธุรกรรมอยู่ที่ 4,500 TPS ซึ่งความเร็วที่กล่าวมานี้ ไม่ใช่ตัวเลขเพื่อการตลาดอย่างที่คุณอาจจะเคยเห็นในหลาย ๆ โปรเจกต์ ที่ทดสอบกับ nodes จำนวนหยิบมือ ด้วย 1 datacenter สำหรับ Avalanche ตัวเลขนี้เป็นข้อมูลจริง ด้วยการปรับใช้อย่างเต็มรูปแบบของ Avalanche network หากมี 2,000 nodes ที่ไปใช้อยู่บน AWS และมีการกระจายตัวอยู่ทั่วโลกด้วย hardware สเปคต่ำ (low-end) ก็จะมีประสิทธิภาพที่สูงกว่าของ VISA (10,000+) ด้วยสมมติฐานที่แต่ละ node ใช้ bandwidth ที่มีความเร็วสูงสักหน่อย (ความเร็วในการ download และ upload) และใช้ hardware ที่ค่อนข้างดี สำหรับการลงชื่อยืนยันความถูกต้อง สิ่งเหล่านี้ยังเป็นตัวชี้วัดในระดับ base-layer วิธีการขยายการรองรับของ layer-2 ช่วยเพิ่มผลลัพธ์เหล่านี้ได้ในทันที
หมายเหตุ: ผู้อ่านสามารถตรวจสอบข้อมูลเกี่ยวกับ validators และการกระจายตัวทางภูมิศาสตร์ของ Avalanche ได้ที่นี่ Statistics: Staking \ AVASCAN
แล้วมันทำงานอย่างไร?
กำหนดให้แต่ละ Validator ต้องทำการสุ่มเลือก nodes (ความน่าจะเป็นที่จะถูกเลือก ดูจากจำนวน AVAX ที่มีการ Stake อยู่ใน node นั้น) เป็นจำนวน K nodes จากจำนวนของ Validators ทั้งหมด เพื่อขอข้อมูล (query) ว่าแต่ละ K nodes นี้ มีผลการตัดสินอย่างไรบ้าง และถ้าผลการตัดสินของ nodes ที่ได้เลือกมาในแต่ละรอบ ซึ่งเสียงส่วนใหญ่ในแต่ละรอบนี้ มีความแตกต่างไปจากตัว validator หรือ node ผู้ที่กำลังขอข้อมูล ซึ่งตัวเองก็มีข้อมูลเป็นของตัวเองเหมือนกัน ตัว node เองนี้ ก็จะอัพเดทผลการตัดสินของตัวเอง ให้เป็นการสะท้อน และตอบสนองไปตามคำตอบของ nodes อื่น ๆ (เดี๋ยวมาดูตัวอย่างกัน)
เพื่อง่ายต่อการอธิบาย รูปด้านล่างนี้แสดงให้เห็นถึงกลุ่มของ Validators ทั้ง 64 Nodes ที่จะต้องทำการเลือกระหว่างสีฟ้า หรือสีเหลือง โดยจำนวน nodes ที่จะถูกสุ่มเลือกเพื่อมาให้ข้อมูล (query) สมมติให้เป็น K = 5 โดยให้สังเกต node มุมซ้ายบนสุด ที่ตอนนนี้แสดงเป็นสีเหลือง ซึ่งเป็นสีที่ node นั้นได้เลือกไว้ก่อนแล้ว จากนั้นมันจะสุ่มเลือก nodes อื่น (ความน่าจะเป็นในการเลือกจะดูจากจำนวนการ Stake ในแต่ละ node) มาจำนวน K ซึ่งก็คือ 5 nodes จากชุดของ validators ทั้งหมด เพื่อให้ข้อมูล (query) ว่าเลือกอะไร (Nodes ทั้ง 5 ที่ถูกเลือกจะทำสัญลักษณ์วงกลมสีแดง)
อย่างที่เราเห็น มี 3 nodes ได้เลือกสีฟ้า ขณะที่อีก 2 nodes เลือกสีเหลือง ตอนนี้สีฟ้าเลยมีน้ำหนักมากกว่าสีเหลือง และ node ซ้ายบนสุดก็ได้ปรับข้อมูลกลายเป็นสีฟ้าในรูปถัดไป
ยังคงให้สังเกตไปที่ node ด้านซ้ายบ้านสุด รอบต่อไปจะมีการสุ่มทำ query เพิ่มอีก 5 nodes และ nodes ที่สุ่มมาใหม่จากรูปด้านล่างนี้นี้ได้เลือกสีฟ้า 4 nodes และ เหลือง 1 node ดังนั้นจึงได้คำตอบในรอบนี้ว่าเป็นสีฟ้า
แต่มีสิ่งสำคัญที่ต้องให้ความสนใจ ในขณะที่เราสังเกต node ด้านซ้ายบนสุดอยู่นั้น nodes อื่น ๆ แต่ละ node เองนั้น ต่างก็มีกระบวนการเดียวกันนี้เกิดขึ้นมา คือสุ่มเลือก nodes ด้วยตัวเอง จำนวน 5 nodes เพื่อ query ในแต่ละรอบ จะเห็นว่าไม่มีการรอกันเกิดขึ้น nodes เหล่านี้จะทำงานด้วยตัวเองอย่างเป็นอิสระ แต่ละ node ได้ส่มเลือก nodes ด้วยตัวเอง ซึ่งรูปด้านล่างนี้ ได้ทำสีไฮไลท์ไว้เป็น 4 กลุ่มของ nodes ที่แต่ละ node ได้สุ่มเลือกมาเป็นจำนวน K = 5 nodes นั่นคือกลุ่มสีแดง ดำ เขียว และสีม่วง เราจะสังเกตเห็นอย่างรวดเร็วว่ากระบวนการนี้ถูกกระจายออกไปยังพัน ๆ nodes และสุดท้าย nodes ทั้งหมดก็จะได้มีส่วนร่วมใน consensus และยังไม่จบเพียงเท่านั้น จะเห็นว่าแต่ละ node มีภาระงานเท่าเดิม คือสุ่มเลือกจำนวน K nodes โดยไม่จำเป็นต้องไปคำนึงถึงจำนวน nodes ทั้งหมดว่ามีอยู่เท่าไหร่
การที่ทุก ๆ validator ได้สุ่มเลือก validators อื่น ๆ เพื่อต้องการรู้ผลการตัดสินของ validators นั้น ๆ ผู้ที่มีส่วนร่วมใน Avalanche มีความมั่นใจจากการตัดสินที่ถูกต้องที่ถูกเผยแพร่ด้วย nodes ทั้งหมดใน network ดังนั้นแต่ละ node ไม่จำเป็นต้อง query เพื่อขอข้อมูลกับ nodes ทั้งหมด เหมือนกับวิธีของ classical consensus สำหรับ Avalanche แต่ละ node จะสุ่มเลือก nodes ด้วยตัวเอง ดังนั้นจึงสามารถที่จะขยายให้มีการรองรับการใช้งานออกไปเป็นหลายแสน หรือหลายล้าน nodes ได้ โดยไม่ต้องเพิ่มระยะเวลาลงไปอีกจำนวนมาก เพื่อการสื่อสารกันของแต่ละ nodes (overhead) และด้วยการ query กับจำนวน nodes ที่คงที่ เมื่อเกิดความมั่นใจที่มากพอ กระบวนการตัดสินก็จะเสร็จสิ้นทันที ซึ่งเป็นกระบวนการที่เกิดขึ้นอย่างรวดเร็วมาก Avalanche ได้แสดงให้เห็นถึงการเป็นระบบการชำระเงินหลัก ที่สามารถจัดการกับธุรกรรมภายใน network ได้ และรูปด้านล่างนี้แสดงให้เห็นถึงกระบวนการใน consensus ที่เสร็จสมบูรณ์ เมื่อทุก nodes ต่างก็ได้ทำการ query โดยใช้สีฟ้า และสีเหลืองเป็นจำนวนที่เท่า ๆ กันแทนผลของการตัดสิน เราจะเห็นว่าผลการตัดสินนั้นมันรวดเร็วแค่ไหน
Avalanche รองรับการโจมตีแบบ arbitrarily ขนาดใหญ่ และ parameterizable set of adversaries ถ้า network ถูกโจมตีด้วย parameterized 33% และผู้โจมตีมี 34% ของจำนวน stake ซึ่งแตกต่างจาก classical consensus protocols ที่สามารถทำให้เกิดการ double spend ซึ่งจะการันตีความสำเร็จ แต่ที่ Avalanche พวกเขามีโอกาสที่จะทำได้ แต่ไม่ได้การันตีว่าจะทำได้สำเร็จ เพราะว่า Avalanche มีการแบ่งกันทำหน้าที่โดยไม่มี leader ซึ่งต้านทานต่อการถูกโจมตีด้วยการใช้ข้อมูลจำนวนมาก ซึ่ง consensus protocol families อื่น ๆ จะเจอกับปัญหาเหล่านี้ และด้วยการที่มี Validators จำนวนมาก จะยิ่งทำให้มั่นใจในความทนทานต่อการถูกโจมตี และทนทานต่อการ censorship (การปิดบังในการทำธุรกรรม หรือการแอบแก้ไขธุรกรรม) ซึ่ง Proof-of-work protocols ไม่สามารถทำได้ เพราะว่ามีเพียงกลุ่มนักขุดจำนวนน้อยรองรับอยู่เท่านั้น
และในตอนนี้เรามี consensus protocols ที่ต่างกันอยู่ 2 protocols คือ Snowman และ Avalanche และกำลังพัฒนา protocols อันที่ 3 ชื่อว่า Frosty ซึ่งอยู่ในแผนงาน ทั้งนี้ Snowman จะมีหน้าที่สร้าง ordered Timeline ทั้งหมด ซึ่งจะต้องใช้ใน Smart contracts ส่วน Avalanche นั้นจะสร้าง ordered Timeline เพียงบางส่วน และไม่ต้องเชื่อมโยงข้อมูลทุกอย่างเข้าด้วยกัน ส่งผลให้สามารถมี throughput (การรองรับปริมาณงานในช่วงเวลาหนึ่ง) ที่สูงกว่าเดิมมาก และมี latency (ความเร็วในการเดินทางของข้อมูล) ที่ดีกว่า สำหรับใช้ในการชำระค่าใช้จ่าย เป็นต้น
ข้อมูลเพิ่มเติมเกี่ยวกับ Avalanche consensus: Avalanche Consensus — Avalanche (avax.network)
Whitepapers เกี่ยวกับ Avalanche consensus: 6009805681b416f34dcae012_Avalanche Consensus Whitepaper.pdf (website-files.com)
Whitepapers เกี่ยวกับ Avalanche ทั้งหมด: Whitepapers (avalabs.org)
เข้าร่วม พูดคุยกับ Avalanche (AVAX) ประเทศไทย บน Telegram: https://t.me/avalanche_th
