กลุ่มอำพัน: ถอดรหัสการออกแบบสถาปัตยกรรมที่ใช้ DAG

ที่มา: แอมเบอร์ กรุ๊ป

ชื่อระดับแรก

"DAG" หมายถึงอะไรกันแน่?

"DAG" เป็นตัวย่อของ "Directed Acyclic Graph" สำหรับผู้ที่ไม่คุ้นเคยกับวิทยาการคอมพิวเตอร์ คำศัพท์เหล่านี้อาจเป็นเพียงคำสั้นๆ เราจึงขออธิบายรายละเอียดแต่ละคำดังนี้

- กำกับ: ข้อมูลของโครงสร้างข้อมูลนี้จะถูกส่งไปในทิศทางเดียวเท่านั้น

- Acyclic (acyclic): ในแง่ของโครงสร้างข้อมูล เป็นไปไม่ได้ที่จะกลับจากสถานะปัจจุบันไปยังสถานะก่อนหน้า นั่นคือ "acyclic"

- กราฟ: ภายใต้การแสดงโครงสร้างข้อมูล โครงสร้างจะแสดงเป็นชุดของความสัมพันธ์ระหว่างจุดยอดหลายจุด

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

รูปด้านบนเป็นตัวอย่างของ "ลำดับทั้งหมด" เมื่อถูกกำหนดว่าเหตุการณ์ใดเกิดขึ้นก่อน เหตุการณ์ทั้งหมดจะมีลำดับที่แน่นอน ในลำดับเหตุการณ์ทั้งหมด เราทราบแน่ชัดว่าแต่ละเหตุการณ์อยู่ในลำดับใด เมื่อใช้ลำดับทั้งหมดตามที่แสดงในรูป เหตุการณ์ A จะเกิดขึ้นก่อน จากนั้นเหตุการณ์ B และเหตุการณ์ C นี่คือวิธีบันทึกเหตุการณ์ในบล็อกเชน

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

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

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

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

รูปด้านบนเป็นตัวอย่างของลำดับสาเหตุ เหตุการณ์ในภาพด้านบนไม่ได้ประทับเวลาไว้ ดังนั้นจึงไม่สามารถระบุได้อย่างแน่ชัดว่าเหตุการณ์เหล่านี้เกิดขึ้นเมื่อใด อย่างไรก็ตาม เราจะเห็นว่า A ทำให้ B เกิดขึ้น และ B ทำให้เกิด C และ E เกิดขึ้น สรุปได้ว่าในที่สุด A ก็ทำให้ D และ F เกิดขึ้น เนื่องจาก C ทำให้เกิด D และ E ทำให้เกิด F เราจึงสามารถกำหนดลำดับสาเหตุของ C และ D และ E และ F ได้ อย่างไรก็ตาม เราไม่จำเป็นต้องกำหนดลำดับของ C และ E หรือ C และ F หรือลำดับของ E ที่สัมพันธ์กับ C หรือ D เหตุการณ์ทั้งหมดไม่ได้เรียงลำดับบางส่วนและสัมพันธ์กันเชิงสาเหตุ แต่ไม่เป็นไรเพราะเหตุการณ์ที่ไม่เกี่ยวข้องไม่จำเป็นต้องเรียงลำดับโดยสัมพันธ์กัน

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

ชื่อระดับแรก

ชื่อเรื่องรอง

blockchain ที่สั่งซื้ออย่างสมบูรณ์ใช้ DAG อย่างไร

ข้อความ

Fantom: บล็อกเชนที่ใช้โปรโตคอล Gossip โดยใช้เทคโนโลยี DAG

คำอธิบายภาพ

ในระดับสูง โหนดจะสร้างบล็อกเหตุการณ์ที่สร้าง DAG Fantom ใช้บล็อกเหตุการณ์ DAG และสร้างบล็อกเชน (สายโซ่ของบล็อกที่ได้รับการยืนยัน)

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

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

จากข้อมูลการสื่อสารระหว่างกัน บล็อก Clotho บรรลุฉันทามติเพื่อสร้างบล็อกเหตุการณ์อีกบล็อกหนึ่ง ซึ่งเรียกว่าบล็อก "Atropos" (บล็อกสีเขียวในแผนภาพด้านบน) แต่ละบล็อกของ Clotho มีการประทับเวลาเฉพาะเมื่อสร้างขึ้น บล็อก Clotho จะกลายเป็นบล็อก Atropos ถ้าอย่างน้อย 2/3 ของโหนดทั้งหมดมีเวลาโหนดเท่ากัน บล็อก Atropos เหล่านี้เชื่อมต่อกันเป็น "ห่วงโซ่หลัก" ห่วงโซ่หลักสามารถถือเป็น blockchain ในโครงสร้าง DAG บล็อก Atropos แต่ละบล็อกเชื่อมต่อกับบล็อก Atropos อื่นๆ แบ่งปันข้อมูลที่รวบรวมจากบล็อก Clothos ซึ่งจะรับข้อมูลจากบล็อกกิจกรรมอื่นๆ ทั้งหมด

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

ชื่อระดับแรก

DAG พร้อมเอาต์พุตที่สั่งตามสาเหตุ

สิ่งที่คนส่วนใหญ่เรียกว่า "DAG" แท้จริงแล้วคือบัญชีแยกประเภทแบบกระจายที่เรียงลำดับตามสาเหตุ DAG เหล่านี้ทำงานอย่างไร และแตกต่างจากคำสั่งซื้อทั้งหมดแบบสัมพัทธ์อย่างไร X-Chain, IOTA และ Sui ของ Avalanche เป็นตัวอย่างของบัญชีแยกประเภทแบบกระจายที่มีการสั่งซื้อเชิงสาเหตุ

Avalanche X-Chain ซึ่งเป็น DAG ที่ใช้ UTXO

Bitcoin เปิดตัวโมเดลเอาต์พุตธุรกรรมที่ไม่ได้ใช้งาน (UTXO) เพื่อบันทึกสถานะการโอนระหว่างกระเป๋าเงิน UTXO แต่ละรายการเป็นสายการเป็นเจ้าของ และเจ้าของลงนามในธุรกรรมที่โอนความเป็นเจ้าของ UTXO ไปยังที่อยู่ของเจ้าของใหม่ ในบริบทของ UTXO ควรอธิบายว่า Bitcoin เป็น blockchain และ X-Chain ของ Avalanche ควรเรียกว่า DAG X-Chain ใช้โปรโตคอลฉันทามติของ Avalanche ตามลำดับสาเหตุ เมื่อคุณส่ง AVAX ให้ผู้อื่น แสดงว่าคุณกำลังใช้ X-Chain เพื่อทำความเข้าใจว่า DAG ของ Avalanche ทำงานอย่างไร คุณต้องทราบก่อนว่าโครงสร้าง DAG ของ Avalanche ก่อตัวขึ้นอย่างไร

ฉันทามติของ Avalanche แบ่งออกเป็นสี่ขั้นตอนหลัก: Slush, Snowflake, Snowball และ Avalanche ขั้นตอนสุดท้ายที่คู่กันกับฉันทามติของ Avalanche คือฉันทามติของ Snowman ซึ่งเราจะสำรวจในภายหลัง ก่อนอื่นเรามาดูว่า Slush Consensus ทำงานอย่างไร เครือข่าย Avalanche ประกอบด้วยโหนดจำนวนมาก แต่ละโหนดมีสามสถานะ: ไร้สถานะ จริง และเท็จ ด้านล่างเราใช้สีเพื่อแสดงความรู้สึกได้ง่ายขึ้น: ไม่มีสี สีน้ำเงิน และสีแดง

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

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

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

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

ขั้นตอนทั้งหมดข้างต้นนำไปสู่โปรโตคอล Avalanche ในที่สุด Avalanche เป็นโครงสร้าง DAG แบบผนวกเท่านั้น (เพิ่มธุรกรรมไปยังธุรกรรมก่อนหน้า) Avalanche ยังสามารถทำงานได้โดยไม่มีโครงสร้าง DAG เช่นเดียวกับโครงสร้างเชิงเส้นของ Avalanche บนสายสัญญา (C-Chain) และสายแพลตฟอร์ม (P-Chain) Team Rocket ซึ่งเป็นทีมพัฒนาของ Avalanche Consensus เชื่อว่าสถาปัตยกรรม DAG เหนือกว่าบล็อกเชน เนื่องจากการลงคะแนนของแต่ละธุรกรรมในสถาปัตยกรรม DAG นั้นเชื่อมโยงกับธุรกรรมทั้งหมดที่เพิ่มเข้ามา ดังนั้นกลไกการลงคะแนนของ DAG จึงมีประสิทธิภาพมากกว่า

ฉันทามติของ Avalanche ประกอบด้วยเหตุการณ์ Snowball หลายเหตุการณ์เพื่อสร้าง DAG แบบไดนามิกของธุรกรรมที่รู้จักทั้งหมด - เหตุการณ์ Snowball แต่ละเหตุการณ์เป็นจุดยอดในกราฟ จุดยอดเป็นเหมือนบล็อกในบล็อกเชนเชิงเส้น ประกอบด้วยแฮชของพาเรนต์และรายการธุรกรรม ฉันทามติของ Avalanche อิงตาม Snowball และแนวคิดของความเชื่อมั่นยังคงใช้ได้ แต่นำไปใช้กับแต่ละโหนดของ DAG แตกต่างจากการตัดสินใจสีแดง-น้ำเงินที่กล่าวถึงก่อนหน้านี้ โหนดในฉันทามติของ Avalanche จะตัดสินว่าธุรกรรมนั้นถูกต้องหรือขัดแย้งกับธุรกรรมอื่นหรือไม่ และบรรลุฉันทามติระหว่างกัน ทุกธุรกรรมเชื่อมโยงกับธุรกรรมหลัก และธุรกรรมหลักทั้งหมดเชื่อมโยงกลับไปที่จุดกำเนิด ธุรกรรมสามารถมีธุรกรรมย่อย และธุรกรรมย่อยเชื่อมโยงกับธุรกรรมหลักทั้งหมด Avalanche ต้องการจุดยอดจุดกำเนิดเนื่องจากต้องมีธุรกรรมเพื่อเป็นพื้นฐานของธุรกรรมอื่นๆ ทั้งหมด (IOTA ก็มีจุดยอดจุดกำเนิดเช่นกัน) จุดยอดจุดกำเนิดมีความสำคัญเนื่องจากธุรกรรมที่รองรับเฉพาะการดำเนินการเพิ่มเท่านั้นที่ต้องการส่วนเพิ่ม อย่างไรก็ตาม หาก Snowball ถูกนำไปใช้กับ DAG ที่ประกอบด้วยโหนดโดยตรง สิ่งนี้จะทำให้เกิดปัญหาที่ไม่ได้รับการแก้ไข ซึ่งก็คือความขัดแย้งในการทำธุรกรรมหรือการใช้จ่ายซ้ำซ้อน ดังนั้น Avalanche จึงเพิ่มแนวคิดของ "จิต" ให้กับสโนว์บอล เมื่อความเชื่อมั่นถึงขีดจำกัด ตัวนับที่เรียกว่า chit จะถูกเพิ่มเข้าไปในธุรกรรมด้วยค่า "1" หากไม่ได้กำหนดไว้ ตัวนับไคตจะเป็น "0" โหนดนี้จะรวมค่าไคตเป็นการตั้งค่าความมั่นใจเพิ่มเติม คล้ายกับ ความมั่นใจของสโนว์บอล จากนั้นโหนดจะใช้ผลรวมของไคตเพื่อกำหนดความเชื่อมั่นของธุรกรรม และธุรกรรมย่อยทั้งหมด (ธุรกรรมใหม่ที่เพิ่มไปยังโหนด)

Avalanche สามารถรวม Slush, Snowflake และ Snowball และปรับให้เป็นสายโซ่เชิงเส้น สิ่งนี้ทำเพื่อฉันทามติ Snowman ควบคู่ไปกับฉันทามติของ Avalanche ซึ่งแตกต่างกันมาก ไม่เหมือนกับโมเดล UTXO ของ Avalanche ตรงที่ฉันทามติของ Snowman จะขึ้นอยู่กับบัญชี ฉันทามติ Snowman ใช้สำหรับห่วงโซ่แพลตฟอร์ม (P-chain) และห่วงโซ่สัญญา (C-chain) ของเครือข่าย Avalanche โปรโตคอลทำงานเหมือนกับด้านบน แต่แต่ละจุดยอดมีพาเรนต์เดียวแทนที่จะเป็นพาเรนต์หลายตัว จุดยอดทั้งหมดจึงรวมกันเป็นลำดับ นอกจากนี้ยังทำให้โครงสร้างโดยรวมเป็น blockchain แทนที่จะเป็น DAG ซึ่งมีประโยชน์สำหรับแอปพลิเคชันที่จำเป็นต้องทราบลำดับการทำธุรกรรม และฉันทามติของ Snowman ยังรองรับสัญญาอัจฉริยะอีกด้วย

โปรโตคอลฉันทามติของ Avalanche ทำงานได้ดีอย่างน่าอัศจรรย์สำหรับการโอนสกุลเงิน และสามารถนำไปใช้กับโปรโตคอลอื่นๆ ที่หลากหลายได้เช่นกัน Avalanche ถูกใช้เป็นกลไกก่อนฉันทามติสำหรับ Bitcoin Cash ก่อนที่จะทำการ hard fork ให้กับโครงการ Bitcoin ABC ของตัวเอง โครงสร้าง DAG ของ Avalanche ช่วยเพิ่มความเร็วในการทำธุรกรรม และเนื่องจาก Bitcoin Cash ไม่ต้องการสัญญาอัจฉริยะ ข้อบกพร่องของ DAG ที่เข้ากันไม่ได้กับสัญญาอัจฉริยะจึงไม่มีผลกับสิ่งนี้ ในฟิลด์การชำระเงิน Avalanche สามารถเพิกเฉยต่อความต้องการสัญญาอัจฉริยะ และเน้นเฉพาะวิธีที่บัญชีแยกประเภทที่ใช้ DAG สามารถขยายฟังก์ชันการทำงานได้อย่างมีประสิทธิภาพมากขึ้น

IOTA ซึ่งเป็น DAG ที่อิงกับธุรกรรมโดยใช้หลักฐานการทำงาน

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

ในแผนภาพด้านล่าง ธุรกรรม G อนุมัติธุรกรรม E และ F การทำธุรกรรมมีข้อมูลเช่น "Alice ให้ Bob สิบเหรียญ IOTA" ธุรกรรมที่ไม่ผ่านการอนุมัติเรียกว่า "ทิป" ธุรกรรม G เป็นเคล็ดลับเนื่องจากยังไม่ได้รับการอนุมัติ ธุรกรรมที่เพิ่มใหม่แต่ละรายการจะต้องเชื่อมโยงกับเคล็ดลับสองข้อที่รอดำเนินการ มีกลยุทธ์สองสามวิธีที่ช่วยในการเลือกทิป แต่วิธีที่ง่ายที่สุดคือการสุ่มเลือกทิปสองอันเพื่ออนุมัติ ขั้นตอนการเลือกเคล็ดลับสำหรับการอนุมัติสามารถปรับขนาดได้อย่างมากสำหรับธุรกรรมใหม่

ธุรกรรมสีแดง I และ G เป็นเคล็ดลับที่ไม่ได้รับอนุมัติ เนื่องจากไม่ได้เชื่อมโยงกับธุรกรรมอื่นๆ ธุรกรรมอื่นๆ ทั้งหมดได้รับการอนุมัติแล้ว เนื่องจากแต่ละธุรกรรมมีธุรกรรมอื่นๆ เชื่อมโยงอยู่ด้วย

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

คำอธิบายภาพ

ธุรกรรมแต่ละรายการมีน้ำหนักของตัวเอง และทุกครั้งที่เพิ่มทิปลงใน Tangle น้ำหนักสะสมจะเพิ่มขึ้น

ในแผนภาพด้านบน เราจะเห็นว่าธุรกรรม D ได้รับการอนุมัติโดยตรงจากธุรกรรม E และ H และโดยทางอ้อมจาก G และ I ดังนั้นน้ำหนักสะสมของ D คือ 3+1+3+1+1=9 ซึ่งเป็นผลรวมของน้ำหนักของมันเองบวกกับน้ำหนักของ E, H, G และ I

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

เช่นเดียวกับ X-Chain ของ Avalanche แนวทางนี้แม้ว่าจะปรับขนาดได้สูง แต่ก็แทบจะเป็นไปไม่ได้เลยที่จะผสานรวมสัญญาอัจฉริยะ ดังนั้น เพื่อที่จะแข่งขันกับห่วงโซ่สัญญาอัจฉริยะอื่น ๆ IOTA จึงเปิดตัวเลเยอร์สัญญาอัจฉริยะแยกต่างหากที่เรียกว่า "แอสเซมบลี" แอสเซมบลีเป็นเลเยอร์ 2 ที่สั่งซื้ออย่างสมบูรณ์ซึ่งออกแบบมาเพื่อรองรับสัญญาอัจฉริยะ EVM และ WASM

Sui สัญญาอัจฉริยะ DAG ที่ใช้ Proof of Stake

แม้ว่า Sui จะถูกจัดประเภทเป็นลำดับเชิงสาเหตุในรายงานนี้ แต่ในความเป็นจริงแล้ว Sui ใช้ทั้งลำดับโดยรวมและลำดับเชิงสาเหตุ สถาปัตยกรรมการประมวลผลธุรกรรมของ Sui สามารถมองเห็นได้เป็นสองส่วน: ส่วนหนึ่งคือคำสั่งรวม ธุรกรรมที่ขึ้นต่อกันที่ดำเนินการตามลำดับ และอีกส่วนคือคำสั่งเชิงสาเหตุ ธุรกรรมอิสระที่ดำเนินการพร้อมกัน ธุรกรรมที่พึ่งพาใช้โปรโตคอล Narwhal และ Bullshark ของ Sui Narwhal เป็น mempool ที่ใช้ DAG ในขณะที่ Bullshark เป็นโปรโตคอลฉันทามติที่รวมเข้ากับ Narwhal เพื่อฉันทามติ การทำธุรกรรมที่พึ่งพาจำเป็นต้องดำเนินการตามลำดับกับธุรกรรมอื่น ๆ ที่เกี่ยวข้องเท่านั้น อย่างไรก็ตาม Sui ใช้แนวทางอื่นเมื่อธุรกรรมเป็นอิสระอย่างสมบูรณ์ สำหรับการทำธุรกรรมแบบสแตนด์อโลน แทนที่จะเป็น Narwhal และ Bullshark Sui ใช้วิธีที่เรียกว่า Byzantine Consensus Broadcasting (BCB) วิธีนี้ไม่ต้องการความเห็นพ้องต้องกันทั่วโลก ดังนั้นธุรกรรมจึงสามารถประมวลผลและเขียนไปยังบัญชีแยกประเภทได้แทบจะในทันที

คำอธิบายภาพ

ธุรกรรมทั้งหมดจะได้รับการประมวลผลแบบขนานบนเครือข่ายเดียวกัน

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

คำอธิบายภาพ

บัญชีแยกประเภทของ Sui คือ "ที่เก็บวัตถุ" หรือ "กลุ่มวัตถุ" ซึ่งข้อมูลถูกเก็บไว้ใน DAG ตัวอย่างเช่น การส่ง USDC คือการอัปเดตคุณสมบัติ "เจ้าของ" ของวัตถุหนึ่ง ซึ่งไม่มีผลกระทบต่อวัตถุอื่นๆ

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

ประเด็นสำคัญ

ประเด็นสำคัญ

การสั่งซื้อธุรกรรมเชิงสาเหตุดูเหมือนจะมีข้อได้เปรียบเหนือการสั่งซื้อทั้งหมดในแง่ของความเร็วและปริมาณงาน อย่างไรก็ตาม การขาดลำดับเชิงสาเหตุทำให้เกิดปัญหาเมื่อพยายามสร้างแอปพลิเคชันที่ต้องมีการเรียงลำดับตามลำดับเวลาอย่างเข้มงวด และหลายโครงการไม่สามารถเรียกใช้สัญญาอัจฉริยะบนสถาปัตยกรรม DAG ได้อย่างถูกต้อง สถาปัตยกรรมที่ได้รับคำสั่งอย่างเต็มที่ของ Fantom คล้ายกับโครงสร้างบล็อกเชนรองรับ EVM และสัญญาอัจฉริยะ แม้ว่า Fantom จะมียอดการสั่งซื้อทั้งหมด แต่นักพัฒนายังคงพบวิธีเพิ่มประสิทธิภาพเลเยอร์ 1 ภายใต้กลไกฉันทามติของ DAG Avalanche เลือกแนวทางที่แตกต่าง โดยสร้างกลไกฉันทามติแยกต่างหาก Snowman เพื่อสนับสนุนการพัฒนา EVM และสัญญาอัจฉริยะที่สะดวกสบาย นอกจากนี้ IOTA ยังได้เลือกแนวทางอื่นและกำลังสร้างเฟรมเวิร์กเพื่อให้ปรับใช้อินสแตนซ์บล็อกเชนบน IOTA ได้อย่างง่ายดาย เพื่อรองรับ EVM และสร้างโครงสร้างพื้นฐานเลเยอร์ 2 ที่สั่งซื้ออย่างสมบูรณ์ได้อย่างมีประสิทธิภาพ การออกแบบที่เป็นเอกลักษณ์ของ Sui มีแนวโน้มดีมาก ธุรกรรมสามารถสั่งได้ทั้งหมดหรือสั่งตามสาเหตุตามต้องการ เข้ากันได้กับสัญญาอัจฉริยะและสามารถลดเวลาแฝงได้

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

ชื่อเรื่องรอง

เกี่ยวกับผู้เขียน

ข้อจำกัดความรับผิดชอบ

ข้อจำกัดความรับผิดชอบ

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

ลิงค์ต้นฉบับ

ลิงค์ต้นฉบับ