hydra – CITTA Pool

Hydra Heads ก้าวแรกสู่ Hydra ฉบับเต็ม

February 4, 2022January 21, 2024

Hydra Head คือ protocol ชุดแรกที่มีความสำคัญมากกับ Cardano ในเรื่องของการ scale

แปลมาจาก https://iohk.io/en/blog/posts/2022/02/03/implementing-hydra-heads-the-first-step-towards-the-full-hydra-vision/

เราได้ทำการทดลองเชิงทฤษฎีแล้ว เราวางรากฐานสำหรับการ scale เพื่อรองรับการใช้งานได้หลากหลาย การรับปริมาณงานมากๆ ของ blockchain (Cardano) ตอนนี้ถึงเวลาแล้วสำหรับระบบที่เติบโตอย่างมั่นคงและการปรับปรุงระบบให้ดียิ่งขึ้น

ด้วยเป้าหมายในการสร้างระบบนิเวศที่เหมาะสมที่สุดเพื่อรองรับและส่งเสริมการพัฒนาแอปพลิเคชันแบบกระจายศูนย์ (DApps) ตอนนี้ Cardano อยู่ในขั้นต้นของ Basho Era ที่มีการใช้งาน Smart Contract แล้ว

Basho เป็นเรื่องเกี่ยวกับการปรับขนาดและการเพิ่มประสิทธิภาพเครือข่าย โปรโตคอลตระกูล Hydra เป็นองค์ประกอบสำคัญสำหรับสิ่งนี้

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

Hydra ทำให้ได้ทรูพุตที่เพิ่มขึ้น มี latency ที่น้อยที่สุด และเป็นโซลูชันที่ประหยัดต้นทุนโดยไม่ต้องใช้พื้นที่จัดเก็บขนาดใหญ่ โปรโตคอล Hydra Head เริ่มเป็นรูปเป็นร่างในปี 2020 และตั้งแต่นั้นมาความคิดของเราก็พัฒนาขึ้น โดยเฉพาะอย่างยิ่งตลอดการใช้งานในระยะเริ่มต้นและการพิสูจน์ขั้นตอนแนวคิด (Proof of Concept – PoC) จากแนวคิดเริ่มต้นนั้น โปรโตคอล Hydra Head ได้ตกผลึก และได้รับการพัฒนาต่อไปสู่การใช้งานที่มากขึ้นบน testnet MVP

เราได้เห็นความตื่นเต้นมากมาย ซึ่งมาพร้อมกับ misconception และ misunderstanding สิ่งเหล่านี้ส่วนใหญ่เกิดขึ้นจากแนวคิด มากกว่าการใช้โปรโตคอลจริงและบล็อกก่อนหน้าบางส่วนของเราอาจมีส่วนทำให้เกิดความเข้าใจผิดเหล่านี้ แต่โปรโตคอล Hydra Head ไม่ได้เป็นเพียงเกี่ยวกับการนำ SPO ไปใช้มากเท่ากับ ‘1 ล้าน TPS’ ทางทฤษฎีเท่านั้น ซึ่งจำเป็นต้องได้รับการอธิบายให้ดีขึ้น

ในบทความนี้ เรา – ทีมวิศวกรรมของ Hydra – ได้สรุปความก้าวหน้าในปัจจุบัน แนวทางของเรา และแผนงานในระยะใกล้และระยะยาวของเรา เราจะอธิบายความเข้าใจผิดบางอย่างให้กระจ่าง ชี้แจงประโยชน์และไตร่ตรองถึงความท้าทายในการพัฒนา

Hydra Head โดยสังเขป

มาทำความรู้จักกับ Hydra Heads อีกครั้ง ซึ่งไม่เพียงแต่เกี่ยวข้องกับเลเยอร์เครือข่ายที่แข็งแกร่งระหว่าง peer และการทำงานร่วมกับ Cardano ledger เท่านั้น แต่ยังรวมถึง on-chain scripts (smart contracts) ที่ขับเคลื่อนวงจรชีวิตของ Hydra Head

Hydra Head เป็น isomorphic state channel ที่ปลอดภัยซึ่งพิสูจน์ได้ พูดง่ายๆ ก็คือ เป็น ledger ขนาดเล็กแบบ off-chain ที่จำกัดผู้เข้าร่วม มันทำงานคล้ายกันกับ ledger หลักบนเครือข่าย แต่มันจะเร็วกว่ามาก

สิ่งแรกที่ต้องเข้าใจคือแชนเนลเป็นเส้นทางการสื่อสารระหว่าง 2 peer ขึ้นไป การเป็นส่วนหนึ่ง Hydra Head หมายถึงการเป็นหนึ่งใน peer เหล่านั้น ช่องการสื่อสารสร้างเครือข่ายแยกที่สามารถพัฒนาขนานกับเครือข่ายหลัก ในเครือข่ายทางเลือกเหล่านี้ ผู้เข้าร่วมจะปฏิบัติตาม concensus algorithm ที่แตกต่าง เรียบง่ายกว่า ทุกคนจำเป็นต้องยอมรับธุรกรรมทั้งหมดที่ไหลผ่าน ผลที่ตามมาก็คือ ในฐานะผู้เข้าร่วม “ฉันจะไม่เสียเงิน ซึ่งเป็นเงินที่ไม่ได้ตกลงไว้อย่างชัดเจนว่าจะเสีย ทำไมน่ะหรือ? เนื่องจากการทำธุรกรรมที่ถูกต้องต้องได้รับการอนุมัติจากฉันอย่างชัดเจน”

เมื่อตั้ง Hydra Head ผู้เข้าร่วมอาจลงเงินไว้ในเครือข่ายย่อย ซึ่งหมายถึงการย้ายเงินจาก on-chain ไปยัง script address ที่ล็อคไว้ภายใต้กฎเฉพาะของ script นั้น ตัว script ได้รับประกันการดำเนินการอย่างปลอดภัยแบบเดียวกับโปรโตคอล on-chain และโดยเฉพาะอย่างยิ่ง ผู้เข้าร่วมไม่สามารถโกงกันได้ อย่างไรก็ตามผู้เข้าร่วมคนใดคนหนึ่งอาจตัดสินใจออกจาก Hydra Head โดยการปิดเมื่อใดก็ได้ ในกรณีนี้ ผู้เข้าร่วมทั้งหมดเดินจากไปพร้อมกับสถานะล่าสุดที่พวกเขาตกลงที่จะออฟไลน์บนเครือข่ายคู่ย่อย

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

เจ้ามือที่โต๊ะ (on-chain script) รับรองว่าผู้คนเล่นตามกฎและไม่โกง ในท้ายที่สุด มีชิปออกมามากพอ ๆ กับที่มีชิปเข้ามา อาจมีการแจกจ่ายไปมาระหว่างเกม แม้ว่าผลลัพธ์สุดท้ายจะเป็นที่รู้กันนอกโต๊ะ แต่ผู้เข้าร่วมเท่านั้นที่รู้ประวัติทั้งหมดที่เกิดขึ้นระหว่างเกม

โปรโตคอลนี้เป็นหนึ่งในชุดโปรโตคอลทั้งหมดที่เรามักเรียกว่า ‘Hydra’ ความพยายามด้านวิศวกรรมในปัจจุบันมุ่งเน้นไปที่การนำโปรโตคอล Hydra Head ไปใช้ตามที่เผยแพร่ใน Hydra: Fast Isomorphic State-Channels โดย Chakravarty et al

ในช่วงปลายปี 2021 Maxim Jourenko, Mario Larangeira และ Keisuke Tanaka ได้ตีพิมพ์บทความต่อยอดของ Hydra Head ที่เรียกว่า Interhead Hydra: Two Heads are Better than One เอกสารนี้นิยามวิธีการเชื่อมต่อระหว่าง Heads สองหัวเข้าด้วยกัน ทำให้เกิดการสร้างเครือข่ายของหัวไฮดราที่เชื่อมต่อถึงกันในระยะยาว ก่อนหน้านี้ มีการกล่าวถึงโปรโตคอลอื่นเช่น ‘Hydra Tail’ อย่างไรก็ตาม สิ่งเหล่านั้นยังอยู่ระหว่างการวิจัย พร้อมกับแนวคิดใหม่ๆ ที่มาจากงานล่าสุดเกี่ยวกับโปรโตคอล Hydra Head

ความเข้าใจผิดเกี่ยวกับ Hydra

เมื่อเร็ว ๆ นี้เราได้เห็นความคิดเห็นมากมายที่กำหนดให้ Hydra เป็นสุดยอดโซลูชันสำหรับ Cardano scalability แน่นอนว่า Hydra Heads เป็นรากฐานที่แข็งแกร่งในการสร้าง scalability layer สำหรับ Cardano สิ่งเหล่านี้เป็นส่วนประกอบสำคัญที่ใช้ประโยชน์จากพลังของ Extended Unspent Transaction Output (EUTXO) model เพื่อเปิดใช้ทางสู่โซลูชันที่ซับซ้อนมากขึ้นไปอีก สิ่งเหล่านี้เป็นองค์ประกอบสำคัญของเส้นทางเดินของ scalability แต่มันไม่ใช่ปลายทางสุดท้าย

ความสามารถในการปรับขนาดไม่ได้อยู่ที่หนึ่งล้าน TPS

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

คิดถึงทางหลวงและยานพาหนะ สามารถดูจำนวน ‘ยานพาหนะต่อวินาที’ (VPS) ที่ทางหลวงสามารถรองรับระหว่างจุดสองจุดได้ หากไม่มีคำจำกัดความทั่วไปว่ายานพาหนะคืออะไร การเปรียบเทียบ 10 VPS กับ 100 VPS ก็ดูเหมือนจะไร้ความหมาย หากรถยนต์ 10 คันในตัวอย่างหมายถึงรถบรรทุกสินค้าขนาดใหญ่ ควรเปรียบเทียบกับรถสกู๊ตเตอร์ 100 คันในแง่ของความสามารถในการจัดส่งหรือไม่ เช่นเดียวกับการทำธุรกรรม ธุรกรรมที่มี native assets หลายร้อยรายการนั้นไม่เหมือนกับการชำระ ADA ครั้งเดียวระหว่างคนสองคน

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

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

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

Hydra Heads ทำ finality ได้เกือบจะทันทีภายใน Head. กระบวนการเปิดและปิด Hydra Head อาจใช้เวลา 2-3 blocks แต่เมื่อสร้างแล้ว ธุรกรรมสามารถไหลผ่านผู้เข้าร่วมที่ทำงานร่วมกันได้อย่างรวดเร็ว เนื่องจาก Hydra Heads ใช้ EUTXO model มันจึงสามารถประมวลผลธุรกรรมที่ไม่ขัดแย้งได้พร้อมๆ กัน ควบคู่ไปกับเครือข่ายที่ดี ช่วยให้สามารถใช้ทรัพยากรที่มีอยู่ได้อย่างเหมาะสมที่สุด การจำลองครั้งแรกของโปรโตคอล Hydra Head ในปี 2020 ทำได้สูงถึง ‘1000 TPS’ ขณะนี้เรากำลังอยู่ระหว่างการเปรียบเทียบการใช้งานจริงของ throughput และ finality

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

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

Use case และบทบาทของ SPOs

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

การวิจัย Hydra ครั้งแรกของเราในปี 2020 ได้เสนอให้ SPOs เป็นผู้ดำเนินการรัน Hydra Head อย่างไรก็ตาม เนื่องจากโปรโตคอล Hydra Head ได้รับการวิจัยและสร้างเพื่อเป็น proof of concept เราสามารถระบุได้อย่างชัดเจนว่าเป็นการเข้าใจผิดที่จะบอกว่ามีเพียง SPO เท่านั้นที่ควรเรียกใช้ Hydra Head เพื่อให้แน่ใจว่าสามารถทำ ledger scalability ได้ อันที่จริง SPO ไม่มีส่วนได้เสียในการเปิด Heads ระหว่างกันโดยไม่มีเหตุผลในการทำธุรกรรม (เช่น การให้ทิปหรือการซื้อขาย NFT เป็นต้น) ในทางหนึ่ง SPO ก็เหมือนกับคนอื่นๆ ที่ใช้โปรโตคอล Hydra Head พวกเขาสามารถเป็นผู้เข้าร่วมและเปิดกับ peer อื่นๆ ได้ ซึ่งจริงๆ ทุกคนที่สนใจก็สามารถทำได้เช่นกัน

เป็นที่ยอมรับว่า SPO นั้นดีในโครงสร้างพื้นฐานด้านปฏิบัติการ และอาจเป็นผู้ใช้กลุ่มแรกๆ ที่ใช้งานอินสแตนซ์ของโปรโตคอล Hydra Head อย่างไรก็ตาม สิ่งนี้อนุญาตเฉพาะ SPO ที่เข้าร่วมเพื่อทำธุรกรรมระหว่างกัน ซึ่งจำกัดกรณีการใช้งานสำหรับ end users เฉพาะการออกแบบระบบเลเยอร์ 2 ขั้นสูงเท่านั้น เช่น โปรโตคอล Interhead Hydra ที่ต้องการตัวกลางในการเรียกใช้โครงสร้างพื้นฐานเพื่อประโยชน์ของ end user

อันที่จริง เราคาดว่าคนที่จะตั้ง Hydra Heads จะเป็นผู้ให้บริการ Hydra Heads as a service (HaaS) เราสามารถบรรลุเป้าหมายนี้ได้โดยไม่ละทิ้งการดูแลเงินทุนโดยการเรียกใช้โครงสร้างพื้นฐานในนามของ end user ซึ่งโดยทั่วไปไม่มีผลประโยชน์หรือทักษะทางเทคนิคในการบำรุงรักษาโครงสร้างพื้นฐานดังกล่าว

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

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

Roadmap

ในฐานะกลุ่มของโปรโตคอลที่จะส่งมอบเมื่อเวลาผ่านไป และจะเกี่ยวข้องกับการออกแบบระบบเลเยอร์ 2 ที่ละเอียดยิ่งขึ้นบนโปรโตคอล Hydra Head สิ่งสำคัญคือเราต้องมีส่วนร่วมกับนักพัฒนาของระบบนิเวศของ Cardano บ่อยๆ ไม่ใช่การเปิดตัวแบบเปรี้ยงปร้าง แต่เป็นการทะยอยปล่อยออกมา เราจำเป็นต้องเข้าใจความท้าทายของนักพัฒนา ตรวจสอบให้แน่ใจว่าได้ตอบสนองความต้องการของพวกเขา และสุดท้ายต้องแน่ใจว่าเรากำลังสร้างสิ่งที่มีประโยชน์ นี่คือเหตุผลที่เรากำลังพัฒนา Hydra Head เป็นโปรเจ็กต์ GitHub แบบโอเพนซอร์ส โดยเริ่มจากการพิสูจน์แนวคิดในช่วงต้นปีที่แล้ว เราจึงเปิดตัวพรีวิวสำหรับนักพัฒนาซอฟต์แวร์เบื้องต้นในเดือนกันยายน (0.1.0) ตามด้วย (0.2.0) ก่อนคริสต์มาส การเพิ่มขึ้นครั้งต่อไป (0.3.0) กำลังจะเกิดขึ้นในเดือนกุมภาพันธ์ เราปฏิบัติตามการกำหนดเวอร์ชันเชิงความหมายและแต่ละรุ่นก่อนเผยแพร่ (0.x.0) จะเพิ่ม feature ที่จะพร้อมใช้งานสำหรับคู่ค้าของเราและผู้ที่ใช้งานในช่วงต้นเพื่อทดสอบบน Cardano private และ public testnet

เรามีความยินดีที่จะประกาศว่าแผนงานของเราพร้อมใช้งานบน Github แล้ว! เพื่อเป็นแนวทางในการมีส่วนร่วมกับชุมชนนักพัฒนาซอฟต์แวร์ของเรา และเพื่อความโปร่งใสเกี่ยวกับความพยายามในการพัฒนา คุณจะพบ issue, feature, milestone และ project board ที่มีอยู่ใน Hydra Head repository

ในขณะที่เรามุ่งการออก version ใหม่ที่มีความหมาย มี feature เด่นๆ ทาง testnet และเข้าสู่ mainnet ในภายหลังด้วยเวอร์ชัน 1.0.0 แผนงานมี tentative date การคาดการณ์เหล่านี้เกิดจากทั้งงานที่ทำจนสำเร็จและประมาณการงานที่เหลืออยู่ข้างหน้า เราจะพิจารณาเนื้อหาและวันที่อย่างสม่ำเสมอในแนวทาง agile เพื่อให้แผนงานถูกต้องที่สุด

Knowledge

Hydra ทางออกเรื่อง Scalability ของ Cardano

September 19, 2021November 6, 2021

Alonzo ทำให้ Cardano มีความสามารถด้าน smart contract ด้าน DApps และการใช้งานด้านอื่นๆ Alonzo เป็นหลักหมุดสำคัญในการผจภัยของ Cardano ความสามารถในการเขียน script ระดับฐาน (base level scripting) ทำให้เราต่อยอดนวัตกรรมและพัฒนา network ไปอีกขั้น และยังเป็นการเริ่มต้นกระบวนการเปลี่ยนแปลง blockchain จากเรื่องของ transaction และ token ไปสู่ความคิดสร้างสรรค์ การรวมเข้ากับการเงิน และการพัฒนาแบบกระจายศูนย์

หนึ่งในการพัฒนาที่น่าตื่นเต้นที่สุดหลังจาก Alonzo คือ Hydra ซึ่งเป็นโซลูชันหลักสำหรับเลเยอร์ 2 (layer 2 solution) จะเป็นการพัฒนาความสามารถด้าน scalability ของ Cardano ไปอีกขั้น โดยเป็นเลเยอร์โปรโตคอลใหม่บนบล็อกเชนเลเยอร์ 1 ที่มีอยู่

ในเครือข่ายบล็อกเชน กลไกการลงฉันทามติ (consensus algorithm) สร้างสภาวะความมั่นคงปลอดภัยและการไม่ไว้วางใจ (secure and trustless) ด้วยการรับรองข้อตกลงประวัติการทำธุรกรรม (block confirmation)

Cardano ใช้ Ouroboros ซึ่งเป็นกลไกการลงฉันทามติแบบ proof-of-stake ที่มีประสิทธิภาพเพื่อการนี้โดยเฉพาะ แต่ Cardano ก็เหมือน permissionless blockchain อื่นๆ ที่ประสบกับความท้าทายเรื่องการขยายเพื่อรองรับปริมาณงาน (throughput) จากการใช้งานในโลกจริง ซึ่งก็คือระบบการจ่ายเงิน (payment) การยืนยันตัวตน (identification) เกม หรือบริการบนมือถือ ซึ่งต้องการการลงฉันทามติระดับภาพรวมในทุกธุรกรรม

ทุกธุรกรรมของ Cardano มีค่าธรรมเนียม (fee) คนที่รันเครือข่ายเช่น stake pool operator (SPO) ทั้งหลายต้องได้รับรางวัล (rewards) อย่างเหมาะสม ดังนั้นค่าธรรมเนียมต้องมากพอให้ SPO อยู่ได้อย่างยั่งยืน และผู้ใช้งานก็ต้องการจ่ายค่าธรรมเนียมในอัตราที่รับได้ ไม่แพงเกินไป นอกจากนี้บล็อกเชนต้องได้รับการป้องกันจากการโจมตีแบบ Denial-of-Service (DoS) ดังนั้นค่าธรรมเนียมต้องไม่ถูกจนเปิดความเสี่ยงต่อ DoS เกินควร คนที่จะทำ DoS จึงต้องจ่ายค่าธรรมเนียมแพงมากจนไม่คุ้มที่จะทำ เรื่องของ storage ก็ต้องคำนึงถึง เพราะธุรกรรมที่เกิดขึ้นตลอดเวลาทำให้ต้องใช้พื้นที่จัดเก็บมากขึ้นเรื่อยๆ และจะเกิดปัญหาในที่สุด ดังนั้นบล็อกเชนที่ประสบความสำเร็จที่สุด ตกเป็นเหยื่อความสำเร็จของตนเอง

Scaling Isomorphically (การขยายโดยมีสัญฐานเหมือนกัน)

เราจะทำสิ่งนี้ได้อย่างไร – โดยใช้วิธีการที่มีประสิทธิภาพมากขึ้นในการประมวลผลธุรกรรมนอกเชนสำหรับผู้ใช้งาน (users’s off-chain transaction) ในขณะที่ใช้เชนหลักเพื่อความมั่นคงปลอดภัย (secure settlement layer) Hydra คงความมั่นคงปลอดภัยระดับเดียวกับเชนหลัก และยังคงทำงานควบคู่กับเชนหลักอย่างหลวมๆ Hydra ไม่ต้องการฉันทามติระดับภาพรวม (global concensus) ทำให้ปรับให้เข้ากับการใช้งานที่หลากหลาย เช่น Hydra ยอมให้กำหนดค่าธรรมเนียมธุรกรรม (Tx Fee) และค่า UTXO ขั้นต่ำ อาจน้อยถึงระดับ 1-2 lovelace ซึ่งจำเป็นมากสำหรับการทำธุรกรรมขนาดเล็กมากๆ (microtransaction)

ที่สำคัญที่สุด Hydra นำเสนอแนวคิด isomorphic state channel (แปลไทยน่าจะประมาณว่า ช่องทางที่สถานะเหมือนกัน) โดยการนำ ledger แนวเดียวกันมาใช้กับ ledger ที่ให้ผลแนวเดียวกันมาใช้ซ้ำบน off-chain ข้างเคียง ซึ่งเรียกว่า Hydra Heads โดยเฉพาะกรณีของ Cardano นี่หมายถึงสามารถใช้งาน native asset, NFT, Plutus script ใน Hydra Head แต่ละตัวได้

Isomorphism อนุญาตให้มีการขยายระบบโดยธรรมชาติ แทนที่จะเป็นแบบยึดติด

ธุรกรรมหลายอย่างที่ตอนนี้ถูกจัดการโดย main-chain หรือ applcation ที่ใช้งานบน main-chain จะได้ประโยชน์โดยตรงจาก Hydra เพราะว่ามันเข้าใจธุรกรรมและลายเซ็นที่มีรูปแบบเดียวกัน นี่ช่วยให้ลดอุปสรรคการเริ่มใช้งาน Hydra สำหรับผู้ใช้งานทั้งหน้าเก่าและหน้าใหม่ ที่สามารถนำโครงสร้างพื้นฐานการทดลองและการทดสอบของ Cardano ในการสร้าง wallet และ applcation ที่เชื่อมต่อกับระบบ layer 2

เรายังสามารถสร้าง Hydra Head โดยไม่ต้องใช้เงินในฝั่งของผู้รับ ซึ่งช่วยให้ผู้ใช้ได้ประสบการณ์ที่ราบรื่น (smooth user experience)

พิสูจน์แนวความคิด (proof of concept)

ทีมเริ่มใช้งาน Hydra Head protocol ระดับพื้นฐาน เพื่อพิสูน์แนวความคิด hydra-node

Developer preview จะพร้อมโชว์ในงาน Cardano Summit ปลายเดือนกันยายน 2564 ซึ่งจะช่วยให้นักพัฒนาหรือคนที่สนใจ สามารถรัน hydra-node แบบ online! โดยจะเปิดใช้งาน Hydra Head ในวงจำกัดและเริ่มทดลองรับธุรกรรม ผู้ใช้จะได้เห็น working protoype ใน testnet เฉพาะกิจ รวมถึงจะได้ benchmarking และเอกสารการใช้งานขั้นต้นที่ Github repository ซึ่งจะยังไม่มีส่วนติดต่อผู้ใช้อย่าง wallet, ui

เรื่อง transaction per second (TPS) เป็นสิ่งที่ต้องพูดถึง มันยากที่จะบอกว่าแค่ไหนคือสำเร็จ เพราะว่ามันเป็นเรื่องของ scalability บางคนให้คะแนนเครือข่ายจากการวัด maximum throughput ของ TPS ในขณะที่การวัดผลที่แบบดั้งเดิม (legacy system) ดูจะสมเหตุสมผลกว่า แม้จะสามารถการคาดการณ์ได้และสอดคล้องกันสูง (ตัวอย่างเช่นเครืองข่ายของ VISA) แต่มันมีประโยชน์น้อยสำหรับระบบที่มีการกระจาย (distributed systems) ทั้งนี้เป้าหมายแรกของเราคือ latency (ความหน่วง – ระยะเวลาที่ธุรกรรมได้รับการยืนยัน) เช่นเดียวกับคนอื่น เป็นอีกวิธีหนึ่งในการวัดความเร็วของธุรกรรมบนบล็อกเชนที่ใช้งานได้จริง ใน mainnet TPS น้อยที่สุดคือมี latency 20 วินาทีในหนึ่ง block นี่เป็นจุดเริ่มต้น

ในเลเยอร์ 2 อย่าง Hydra เป็นไปได้ที่จะใช้เวลาในการยืนยันธุรกรรมด้วยเวลาที่น้อยกว่า 1 วินาที

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

Hydra วิวัฒนาการตามกาลเวลา

ระยะสั้น IOHK จะพัฒนา hydra-node และ Hydra Head protocol จนกว่ามันจะกลายเป็นรากฐานที่มั่นคงและเป็นฐานที่มั่นคงสำหรับชุมชน (รวมทั้งทีมงาน IOHK) เพื่อสร้างแอพที่ใช้งานในโลกความเป็นจริง แอพเหล่านี้จะได้ประโยชน์จากความเร็วและค่าธรรมเนียมที่ถูกมาก (low-to-no-cost) เรากำลังพัฒนาฟีเจอร์หลักอื่นๆ อย่างแข็งขัน รวมถึงการรองรับหลายหัวต่อ node การคงอยู่ (persistence) และส่วนขยายของ Head protocol

ระยะกลาง ประมาณ 6-12 เดือน ความก้าวหน้าขึ้นอยู่กับผลของการค้นคว้าและการทดลอง รวมทั้งข้อเสนอแนะจากชุมชนนักพัฒนา (developer community) IOHK กำลังค้นคว้าวิธีการเชื่อมต่อ Hydra heads หลายๆ แบบเพื่อเพิ่มการเข้าถึง layer 2 solution, การทดสอบว่าทำอย่างไรให้ integrate และใช้งาน Hydra ได้ง่ายขึ้น

หนึ่งในวิสัยทัศน์ระยะยาวอันน่าตื่นเต้น คือการพัฒนา Virtual Heads โดยการรัน Hydra Head protocol ข้างใน Hydra Heads อีกชั้นนึง นั่นจะเป็นการใช้งาน isomorphicism แบบเต็มที่ของ layer 2 solution ของ IOHK ซึ่งหากเป็นจริง มันหมายถึงความสามารถในการขยายขนาดไม่จำกัดตามทฤษฎี

ความยืดหยุ่นคือหัวใจของขยายและการเติบโต (scalability & growth)

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

Hydra ลอกการทำงานของ main-chain ในขณะที่ลดแรงเสียดทานของผู้ใช้ แต่ก็ยังยอมให้มีความยืดหยุ่นของการมีค่าธรรมเนียม/โครงสร้างราคาที่แตกต่างกัน และข้อจำกัดด้านเวลาบน layer 2

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

ด้วย Alonzo hardfork ทำให้ Cardano เริ่มก้าวต่อไปในฐานะ smart contract platform การใช้งานเทคโนโลยีอย่าง Hydra จะช่วยปรับปรุงความสามารถในการปรับขนาดของ Cardano ได้อย่างมาก และนำไปสู่การนำไปใช้ต่อไป

Source: https://iohk.io/en/blog/posts/2021/09/17/hydra-cardano-s-solution-for-ultimate-scalability/