เรียนรู้ว่า Bitcoin Merkelized Abstract Syntax Tree คืออะไร
ชื่อเดิม: "สินค้าแห้ง | โครงสร้างไวยากรณ์ของ Bitcoin Merkelization คืออะไร? " โดย เดวิด เอ. ฮาร์ดิง
Merklized Abstract Syntax Trees (MAST) เป็นการอัปเกรดที่เสนอสำหรับ Bitcoin ที่ช่วยให้ขนาดธุรกรรมเล็กลง ความเป็นส่วนตัวที่ดีขึ้น และสัญญาอัจฉริยะที่ใหญ่ขึ้น ในบทความนี้ เราจะอธิบายเหตุผลของ MAST อธิบายถึงประโยชน์ที่อาจเกิดขึ้น และสรุปข้อเสนอปัจจุบันบางส่วนที่ใช้เทคโนโลยีนี้
ปัญหา: ข้อมูลสคริปต์ที่ไม่ได้ใช้
Satoshi Nakamoto ให้คุณลักษณะ Bitcoin ที่น่าสนใจซึ่งเขาไม่ได้เขียนไว้ในสมุดปกขาวของ Bitcoin นอกเหนือจากการรับบิตคอยน์ผ่านคีย์สาธารณะและการใช้จ่ายบิตคอยน์ด้วยลายเซ็นดิจิทัลคีย์ส่วนตัวแล้ว ผู้ใช้ยังสามารถเขียนโปรแกรม (เรียกว่า "สคริปต์") ที่สามารถใช้เป็นคีย์สาธารณะและลายเซ็นแบบไดนามิกได้
เมื่อคุณระบุสคริปต์ ซึ่งเป็นการทำงานพื้นฐานในกระเป๋าเงิน Bitcoin ทุกใบ โปรโตคอล Bitcoin ที่บังคับใช้โดยเครือข่าย Bitcoin จะไม่อนุญาตให้ใครใช้ Bitcoins ที่ควบคุมโดยสคริปต์ เว้นแต่สคริปต์จะคืนค่าจริง สิ่งนี้ทำให้คุณสามารถระบุเงื่อนไขที่สามารถใช้จ่ายเงินได้ ซึ่งเรียกว่า "ภาระผูกพัน" (เงื่อนไขคุณสมบัติ) เช่น กำหนดให้ธุรกรรมที่ต้องใช้ต้องลงนามโดยคีย์ส่วนตัวของคุณ
เงื่อนไขคุณสมบัติที่ซับซ้อนมากขึ้นก็เป็นไปได้ เช่นตัวอย่างต่อไปนี้ ซึ่งเราจะใช้ตลอดทั้งบทความนี้: Alice ต้องการที่จะสามารถใช้ bitcoins ของเธอได้ตลอดเวลา แต่ถ้าเธอไม่ใช้ bitcoins ของเธอเป็นเวลาสามเดือนติดต่อกัน (อาจถึงแก่ชีวิต หรือไร้ความสามารถ) เธอต้องการให้บ็อบและชาร์ลีพี่น้องของเธอเป็นเจ้าของบิตคอยน์และใช้ทุกที่ที่ตกลงกันได้
สคริปต์เงื่อนไขต่อไปนี้บรรลุเป้าหมายข้างต้น ไม่เพียงรวมคีย์สาธารณะของอลิซ (ต้องตรวจสอบลายเซ็นจากคีย์ส่วนตัวของเธอ) แต่ยังเพิ่มตรรกะเงื่อนไขต่อไปนี้: เงื่อนไขการหมดเวลา และคีย์สาธารณะของบ็อบและชาร์ลี
ในโปรโตคอล Bitcoin ปัจจุบัน ข้อมูลทั้งหมดที่กล่าวถึงข้างต้นจะต้องถูกเพิ่มลงในบล็อกเชน และเมื่อ Bitcoin ของอลิซถูกใช้ไป ข้อมูลดังกล่าวยังรวมถึงบางส่วนของสคริปต์ที่ไม่เกี่ยวข้องกับพฤติกรรมการใช้จ่ายที่เฉพาะเจาะจง ซึ่งจะต้องถูกเปิดเผยด้วย ตัวอย่างเช่น เมื่ออลิซใช้บิตคอยน์ของเธอ กุญแจสาธารณะของบ็อบและชาร์ลีก็จะถูกเปิดเผยเช่นกัน
ข้อมูลตามเงื่อนไขที่ไม่ได้ใช้จะเพิ่มขนาดของธุรกรรมและทำให้ผู้ใช้ได้รับความเป็นส่วนตัวมากเกินความจำเป็น พร้อมกันนี้ ยังทำให้ขนาดแทนการตรวจสอบต้นทุนเป็นปัจจัยจำกัดหลักสำหรับขนาดสัญญาอัจฉริยะ MAST มีจุดมุ่งหมายเพื่อปรับปรุงสถานการณ์เหล่านี้โดยขจัดความจำเป็นในการรวมส่วนที่ไม่ได้ใช้ของสคริปต์โดยตรงบนบล็อกเชน
แนวคิดเริ่มต้นของ MAST
แนวคิดเบื้องหลัง MAST 1 มาจากแนวคิดที่มีมาอย่างยาวนาน 2 แนวคิด ต้นไม้ความหมายเชิงนามธรรมและต้นไม้ Merkle Abstract Semantic Tree (AST) เป็นวิธีการอธิบายโปรแกรมโดยการแบ่งโปรแกรมออกเป็นชิ้นเล็กๆ อิสระ ซึ่งทำให้โปรแกรมวิเคราะห์และปรับให้เหมาะสมได้ง่ายขึ้น ในการสร้าง AST คุณต้องเชื่อมต่อสมการทั้งหมดกับสถานที่ด้วยลูกศรจนกว่าจะพบสถานที่ทั้งหมด รูปด้านล่างคือ AST ของสคริปต์ตัวอย่างด้านบน
ในทางกลับกัน ต้นไม้ Merkle สามารถใช้เพื่อตรวจสอบว่าองค์ประกอบนั้นอยู่ในชุดหรือไม่โดยไม่ทราบภาพรวมทั้งหมดของชุด ตัวอย่างเช่น Simple Payment Verification Wallet (SPV wallet) ของ Bitcoin ใช้ Merkle tree เพื่อตรวจสอบว่าธุรกรรมบางอย่างมีอยู่ในบล็อกใดบล็อกหนึ่งหรือไม่ ดังนั้นจึงไม่จำเป็นต้องดาวน์โหลดบล็อกทั้งหมด ซึ่งจะช่วยประหยัดแบนด์วิธได้
ในการสร้าง Merkle tree ขั้นแรกให้แฮชแต่ละองค์ประกอบหนึ่งครั้งเพื่อสร้างตัวระบุเฉพาะของมันเอง จากนั้นตัวระบุเหล่านี้จะถูกจับคู่และแฮชอีกครั้งเพื่อสร้างตัวระบุของคู่ตัวระบุ และทำซ้ำไปเรื่อยๆ จนกว่าจะเหลือตัวระบุเพียงตัวเดียว ซึ่งเรียกว่า "ราก Merkel" ซึ่งเป็นตัวระบุสั้น ๆ ที่ทำเครื่องหมายคอลเล็กชันทั้งหมด
เมื่อตรวจสอบว่าองค์ประกอบเป็นของชุด คนที่เป็นเจ้าของชุดทั้งหมดสามารถให้ตัวระบุทั้งหมดบนเส้นทางจากองค์ประกอบนั้นไปยังราก Merkle นี่เป็นการพิสูจน์ว่าองค์ประกอบนั้นอยู่ในเซตจริงๆ
กล่าวโดยสรุปคือ เทคโนโลยีที่อยู่เบื้องหลัง AST ช่วยให้คุณสามารถแบ่งโปรแกรมออกเป็นส่วนเล็กๆ และ Merkle tree ช่วยให้เราสามารถตรวจสอบได้ว่าชิ้นส่วนเล็กๆ เหล่านี้เป็นส่วนหนึ่งของโปรแกรมที่สมบูรณ์จริงๆ โดยไม่ต้องเปิดเผยโปรแกรมทั้งหมด นี่คือหลักการพื้นฐานของ MAST ซึ่งช่วยให้ผู้บริโภคสามารถแทนที่เงื่อนไขที่ไม่ได้ใช้ในธุรกรรมเดียวด้วยหลักฐาน Merkle - ลดขนาดธุรกรรม ปรับปรุงความเป็นส่วนตัว และสนับสนุนสัญญาที่ใหญ่ขึ้น
ตัวอย่างของ MAST
ลองใช้เงื่อนไขคุณสมบัติข้างต้นเป็นตัวอย่าง และแบ่งออกเป็นสองส่วนย่อยสำหรับสองสถานการณ์ที่เป็นไปได้ที่เราต้องการ:
อลิซสามารถใช้ bitcoins ของเธอได้ตลอดเวลา (ตัวห้อยด้านซ้าย)
หรือหากลายเซ็นของอลิซถูกใช้เพื่อใช้จ่ายเป็นเวลาสามเดือนติดต่อกัน ลายเซ็นของบ็อบและชาร์ลีจะต้องใช้บิตคอยน์ (ตัวห้อยด้านขวาในรูปด้านล่าง)
สร้าง Merkle tree โดยอิงจาก subscripts สองตัวนี้:
ในที่สุดรากของต้นไม้ Merkle นี้ก็ระบุเงื่อนไขคุณสมบัติที่สมบูรณ์ของ Alice และมีขนาดเพียง 32 ไบต์เท่านั้น หลังจากนั้น Alice สามารถใช้สคริปต์แบบมีเงื่อนไขทางเลือก โดยระบุว่าธุรกรรมการใช้จ่ายจะใช้ได้ก็ต่อเมื่อมีตัวห้อยตัวใดตัวหนึ่งที่มีหลักฐานว่าเชื่อมต่อกับรากของ Merkle และรูทีนย่อยส่งคืนค่า True
หลักฐาน Merkle ของตัวห้อยจะวาดเป็นภาพต่อไปนี้ ขึ้นอยู่กับว่าตัวห้อยใดใช้:
ประโยชน์ #1 - ธุรกรรมขนาดเล็ก
ก่อนอื่น มาดูกันว่า MAST ช่วยให้ผู้ใช้ที่มีเงื่อนไขคุณสมบัติซับซ้อนสร้างธุรกรรมที่มีขนาดเล็กลงได้อย่างไร นี่คือประโยชน์แรกที่ MAST มอบให้เรา
ในตัวอย่างด้านบน เราใช้แถบคุณสมบัติที่มีตัวห้อยสองตัว: Alice ใช้เงินของเธอเอง หรือ Bob และ Charlie ใช้เงินของเธอด้วยกันหลังจากรอสามเดือน ลองนึกภาพเวอร์ชันที่ยืดออกอย่างไม่มีที่สิ้นสุด โดยที่ตัวห้อยตัวที่สามระบุว่าหลังจากสามเดือนกับหนึ่งวัน Dan และ Edith สามารถใช้เงินได้ ส่วนตัวห้อยตัวที่สี่ระบุว่าหลังจากสามเดือนกับสองวัน Fred และ George สามารถใช้เงินได้ ฯลฯ เป็นต้น .
การทดลองทางความคิดนี้นำเราไปสู่กราฟด้านล่าง ซึ่งแสดงความสัมพันธ์ระหว่างจำนวนตัวห้อยและจำนวนข้อมูลตามเงื่อนไขที่ต้องเพิ่มลงในบล็อก โดยมีและไม่มี MAST
นี่คือพล็อตลอการิทึมซึ่งมีความหมายเหมือนกัน:
แม้ว่าขนาดของธุรกรรม MAST จะใหญ่กว่าธุรกรรมที่มีเงื่อนไขเดียวกันโดยไม่มี MAST ที่จุดเริ่มต้น เช่น เงื่อนไขของสคริปต์ย่อยทั้งสองของเรา ขนาดธุรกรรมที่ไม่ใช่ MAST จะเพิ่มขึ้นเชิงเส้น (ด้วยจำนวนของสคริปต์ย่อย) ในขณะที่ปริมาณของธุรกรรม MAST จะเพิ่มขึ้นเป็นลอการิทึมเท่านั้น
หากการประหยัดปริมาณข้อมูลเป็นเป้าหมายหลัก เราสามารถเพิ่มประสิทธิภาพเพิ่มเติมได้ สำหรับเงื่อนไขคุณสมบัติหลายๆ อย่าง ผู้บริโภคอาจใช้เงื่อนไขข้อใดข้อหนึ่งบ่อยกว่า ตัวอย่างเช่น อลิซต้องการมีชีวิตที่ยืนยาว ดังนั้นต้นไม้ Merkle ที่เธอสร้างขึ้นจึงวางเงื่อนไขการใช้จ่ายของเธอไว้ใกล้กับจุดสูงสุด และเงื่อนไขอื่นๆ ทั้งหมดจะถูกวางไว้ที่ด้านล่างของต้นไม้:
จะเห็นได้ว่าเมื่ออลิซใช้เงิน จำนวนของข้อมูลการทำธุรกรรมจะเป็นสถานการณ์ที่เหมาะสมเสมอ ไม่ว่าทรัพย์สินของเธอจะมีผู้รับประโยชน์กี่คนก็ตาม และเมื่อผู้รับผลประโยชน์ของเธอใช้เงินทุน จำนวนของข้อมูลธุรกรรมก็เป็นเช่นกัน เหมือนกัน มีเพียงไม่กี่ไบต์ที่มากกว่ามาตรฐานดังกล่าวที่สร้าง Merkle tree
ไม่ว่าอลิซจะเลือกการจัดการแบบใด จะเห็นได้ว่า MAST สามารถทำให้ธุรกรรมที่มีเงื่อนไขหลายตัวห้อยมีขนาดเล็กลง ดังนั้นผู้ใช้จึงสามารถจ่ายค่าธรรมเนียมน้อยลง และธุรกรรมขั้นสูงสามารถโหลดลงในบล็อกได้
ประโยชน์ #2 - ความเป็นส่วนตัวมากขึ้น
ในคำอธิบายข้างต้น เราได้เปิดโปงสคริปต์ทรัพย์สินทั้งหมดของ Alice แต่คุณสามารถจินตนาการได้ว่าถ้า Alice ใช้ bitcoins ของเธอเอง คุณจะเห็นเฉพาะข้อมูลทางด้านซ้ายของภาพด้านล่างบนบล็อกเชน:
ด้วยข้อมูลนี้เท่านั้น คุณไม่มีทางรู้ได้เลยว่าคนอื่นนอกจากอลิซสามารถใช้เงินที่นี่ได้หรือไม่ และพวกเขาต้องเผชิญกับข้อจำกัดอะไรบ้างเมื่อใช้จ่าย คุณสามารถเดาได้จาก MAST ว่าอาจมีเงื่อนไขอื่น ๆ แต่นั่นเป็นเพียงการเดา - อลิซอาจแสร้งทำเป็นว่าต้น Merkle ของเธอมีส่วนอื่นที่ใช้จ่ายได้
ดังนั้นหากคุณเห็นสาขาอื่น (นั่นคือสคริปต์ย่อยทางด้านขวาในภาพด้านบน) คุณจะไม่ทราบว่าสามารถใช้เงินก่อนหมดเวลาได้หรือไม่ และคุณจะไม่ทราบว่าสามารถใช้จ่ายกับ แค่ไพรเวทคีย์ก็ใช้จ่ายได้ คุณสามารถเดาได้ว่ามีเงื่อนไขการใช้จ่ายอื่น ๆ แต่คุณไม่สามารถยืนยันสิ่งนี้บนบล็อกเชนได้
มีประโยชน์มากในการตรวจสอบให้แน่ใจว่าสภาพของทรัพย์สินที่ไม่ได้ใช้ไม่ถูกเปิดเผย ตัวอย่างเช่น ผู้ค้าบางรายอาจต้องการให้สัญญาอัจฉริยะของพวกเขาเป็นความลับมากที่สุดเท่าที่จะเป็นไปได้และไม่ให้คู่แข่งที่มีศักยภาพมองเห็นได้ สิ่งนี้ตรงกันข้ามกับ altcoins บางตัวที่อ้างว่าได้รับการออกแบบมาสำหรับสัญญาอัจฉริยะ แต่ในความเป็นจริงไม่สามารถให้ความเป็นส่วนตัวสำหรับสัญญาเหล่านี้ได้
ความเป็นส่วนตัวยังสามารถให้ประโยชน์เพิ่มเติมแก่ผู้ใช้ Bitcoin ทุกคน แม้ว่าผู้ใช้บางคนจะไม่สนใจความเป็นส่วนตัวในแง่ของทรัพย์สินก็ตาม สมมติว่าตั้งแต่ต้นบทความนี้ Alice เป็นคนเดียวที่ใช้เทมเพลตแบบมีเงื่อนไขที่ไม่ใช่ MAST เนื่องจากเงื่อนไขทั้งหมดเป็นแบบสาธารณะ ทุกคนสามารถติดตามพฤติกรรมการใช้จ่ายของอลิซได้ เพียงแค่สังเกตการใช้งานเทมเพลตนี้บนบล็อกเชน ดังนั้นความเป็นส่วนตัวของอลิซจึงหมดไป
การออกแบบใดๆ ก็ตามที่ทำให้ระบุผู้ใช้รายใดรายหนึ่งได้ง่ายขึ้นจะทำให้ผู้คนสามารถปฏิบัติต่อบิตคอยน์ของตนแตกต่างจากบิตคอยน์ของผู้อื่นได้ง่ายขึ้น ซึ่งเรียกว่า "การขาดความเป็นเนื้อเดียวกัน" หากมีใครรู้ว่าสภาพทรัพย์สินของอลิซเป็นอย่างไร พวกเขาสามารถติดสินบนหรือบังคับให้คนงานเหมืองไม่บรรจุการทำธุรกรรมของคนเหล่านี้ เพื่อป้องกันไม่ให้อลิซใช้บิตคอยน์ของเธอเอง
MAST ไม่สามารถแก้ปัญหานี้ได้อย่างสมบูรณ์ เนื่องจากอลิซ (หรือบ็อบและชาร์ลี) ยังคงต้องเปิดเผยอุปสรรคบางประการ แต่เงื่อนไขคุณสมบัติที่ซับซ้อนหลายอย่างสามารถแก้ไขเป็นเงื่อนไขประเภท MAST ง่ายๆ จำนวนเล็กน้อยได้
ตัวอย่างเช่น พฤติกรรมการใช้จ่ายเริ่มต้นของ Alice ดูเหมือนพฤติกรรมการชำระเงินทั่วไปอื่นๆ ที่ต้องระบุเพียงลายเซ็นเดียว ดังนั้นธุรกรรมที่ใช้ MAST ของ Alice จึงไม่แตกต่างจากธุรกรรมที่ใช้ MAST ที่ใช้ลายเซ็นเดียวอื่นๆ สิ่งนี้จะช่วยปรับปรุงความเป็นส่วนตัวของ Alice รวมถึงความสม่ำเสมอของเงินทุนของเธอ และความสม่ำเสมอทางการเงินสำหรับผู้ใช้ทั้งหมดโดยใช้เงื่อนไขลายเซ็นเดียวที่ยึดตาม MAST
ประโยชน์ของ MAST นี้มีแนวโน้มที่จะรวมกับข้อเสนออื่น ๆ เพื่อปรับปรุงความเป็นส่วนตัวและความสม่ำเสมอของ Bitcoin มีข้อเสนอที่จะทำให้เงื่อนไขคุณสมบัติที่ซับซ้อนบางอย่างพร้อมใช้งานด้วยลายเซ็นเดียว เช่น "Universal Threshold Tree" ของ Pieter Wuille และ Gregory Maxwell "Scriptless Script" ของ Andrew Poelstra และ "สัญญาลอการิทึมแบบไม่ต่อเนื่อง ” ของ Thaddeus Dryja; MAST สามารถใช้ร่วมกับเงื่อนไขเหล่านี้ได้ แผนการ
แม้ว่าจะไม่สามารถนำโซลูชันเหล่านี้ไปใช้กับ Bitcoin ได้ แต่ MAST เองก็สามารถให้ความเป็นส่วนตัวและการแลกเปลี่ยนได้มากขึ้นสำหรับผู้ใช้ที่มีเงื่อนไขคุณสมบัติที่ซับซ้อน ไม่ว่าจะเปรียบเทียบกับปัจจุบันหรือสนับสนุนสัญญาอัจฉริยะ Altcoins ที่ผู้ใช้กำหนด
ประโยชน์ #3 - สัญญาอัจฉริยะที่ใหญ่ขึ้น
ตอนนี้ Bitcoin กำหนดขีดจำกัดขนาดที่แตกต่างกันสามแบบสำหรับแต่ละสคริปต์: สคริปต์เปลือยต้องมีขนาดไม่เกิน 10,000 ไบต์ซึ่งเปิดตัวในเดือนกรกฎาคม 2010 สคริปต์ P2SH ต้องมีขนาดไม่เกิน 520 ไบต์ และสคริปต์ segwit ต้องมีขนาดไม่เกิน 10,000 ไบต์ เราแสดงขนาดเหล่านี้ในรูปด้านบน:
จะเห็นได้ว่าแม้ในกรณีสุดโต่งของการขยายไม่สิ้นสุด MAST รองรับสาขาที่มีเงื่อนไขมากกว่ากลไกปัจจุบันทั้งหมด ในความเป็นจริง MAST ปรับขนาดได้ดีถึงแม้ว่าคุณจะมีพลังงานทั้งหมดในเอกภพที่สังเกตได้ แต่ถ้าคุณใช้มันเพื่อสร้าง Merkle tree มาตรฐาน (สมดุล) หลักฐาน Merkle ของมันมีเพียง 8448 ไบต์เท่านั้น แม้สำหรับหลักฐาน Merkle ขนาดใหญ่เช่นนี้ แล็ปท็อปสมัยใหม่ก็สามารถตรวจสอบได้ภายในเวลาไม่ถึง 1 มิลลิวินาที
MAST ยังสามารถช่วย Bitcoin Script ข้ามข้อจำกัดที่เข้มงวดอื่น ๆ โดยทำให้โหนดทั้งหมดว่างจากงานในการประมวลผลตัวห้อยที่ไม่ได้ใช้ ในเรื่องนี้ MAST ได้รักษาและขยายเป้าหมายการออกแบบระยะยาวของสัญญาอัจฉริยะ Bitcoin นั่นคือภาระของสัญญาควรเป็นภาระของผู้เข้าร่วมสัญญาให้มากที่สุดเท่าที่จะเป็นไปได้ ในขณะที่โหนดจ่ายค่าแบนด์วิดท์ หน่วยความจำและกำลังการประมวลผล แต่ไม่สามารถชดเชยได้ ดังนั้นควรรับผิดชอบให้น้อยที่สุด
ดังนั้น ความสำเร็จที่แท้จริงของ MAST ไม่ใช่การอนุญาตให้ผู้ใช้ Bitcoin สร้างสัญญาขั้นสูง (มากกว่าที่เคย) แต่เป็นการเปิดโอกาสนี้โดยไม่ต้องเพิ่มภาระใหม่ให้กับโหนด Bitcoin
การใช้ MAST: ข้อเสนอหลายรายการที่มีอยู่
จนถึงขณะนี้ มีการเสนอวิธีการสองวิธีในการเปิดใช้งาน MAST ในโปรโตคอล Bitcoin ในรายชื่อผู้รับจดหมาย bitcoin-dev ซึ่งทั้งสองวิธียังคงอยู่ในขั้นร่างและอาจมีการเปลี่ยนแปลงได้
ข้อเสนอแรกคือ BIP114 ที่เสนอโดย Johnson Lau (นามแฝง "jl2012") ซึ่งใช้คุณลักษณะเพิ่มเติมตามพยานที่แยกจากกัน เพื่อให้ที่อยู่ของพยานที่แยกจากกันเดิม (bech32) สามารถกลายเป็นข้อผูกมัดหลักของ Merkle ต่อเงื่อนไขคุณสมบัติ MAST การทำธุรกรรมการใช้จ่ายสามารถเลือกสคริปต์ลูกจากแผนภูมิ
ข้อเสนอที่สอง BIP ที่ไม่มีชื่อสองรายการ (1, 2) โดย Mark Friedenbach (นามแฝงว่า "maaku") เพิ่มความยืดหยุ่นของภาษาสคริปต์ ทำให้โปรแกรมเมอร์สามารถเขียนสคริปต์เพื่อตรวจสอบเงื่อนไขคุณสมบัติตาม MAST ดำเนินการตามวิธีที่ Friedenbach ต้องการ ซึ่งจะทำให้การพิสูจน์ของ Merkle พร้อมใช้งานสำหรับสคริปต์ทั้งสามประเภทที่ Bitcoin รองรับในปัจจุบัน (สคริปต์เปล่า, P2SH และสคริปต์ Segregated Witness)
ข้อเสนอเหล่านี้มีข้อดีและข้อเสียในตัวเอง แต่ทั้งหมดให้ประโยชน์ของ MAST ที่กล่าวถึงข้างต้น (จำนวนไบต์อาจเพิ่มขึ้นหรือลดลง) แต่ละอันสามารถเปิดใช้งานได้ด้วยส้อมแบบนิ่ม
สรุป: เราจะใช้ MAST ได้เมื่อใด
ข้างต้น เราได้อธิบายถึงประโยชน์ของ MAST และกล่าวถึงข้อเสนอสองข้อสั้น ๆ ในการนำ MAST ไปใช้กับ Bitcoin คุณอาจสงสัยว่าเมื่อใดที่เราสามารถใช้ MAST ได้ น่าเศร้าที่ฉันไม่รู้เหมือนกัน
จากแนวคิด ข้อเสนอ การดำเนินการให้เสร็จสมบูรณ์ การเสนอ soft fork ไปจนถึงการเปิดใช้งาน soft fork หนทางยาวไกลและยากลำบาก สิ่งนี้ชัดเจนขึ้นอย่างมากจากดราม่าสองปีเกี่ยวกับการอัปเกรด Segregated Witness
แต่จากมุมมองของฉัน แนวคิดพื้นฐานเบื้องหลัง MAST ได้รับการสนับสนุนอย่างกว้างขวางในชุมชนเทคโนโลยี Bitcoin และนักพัฒนาที่สนใจ MAST มากที่สุดจะยังคงพัฒนาต่อไป เว้นแต่จะมีใครพิสูจน์ได้ว่าเทคโนโลยีนี้ไม่น่าเชื่อถือโดยสิ้นเชิง เมื่อนักพัฒนาเหล่านี้เสนอรหัส soft fork ที่ตรวจสอบโดยเพื่อนได้สำเร็จ ผู้อ่านและผู้ใช้ Bitcoin รายอื่นจะตัดสินใจว่า MAST สามารถเป็นส่วนหนึ่งของโปรโตคอล Bitcoin ได้หรือไม่
ขอบคุณ
BIP114: Merklized Abstract Syntax Tree by Johnson Lau
Tail Call Sematics by Mark Friedenbach
MerkleBranchVerify opcode by Mark Friedenbach
Discussion at core.tech meetup by Mark Friedenbach (transcribed by Bryan Bishop)
Merklized Abstract Syntax Trees by Jeremy Rubin, Manali Naik, Nitya Subramanian
An explanation and justification of the tail-call and MBV approach to MAST by Mark Friedenbach
Making MAST Meaningful by Brian Deery
The next step to improve Bitcoin by Aaron van Wirdum
ขอบคุณ
เชิงอรรถ
เชิงอรรถ
Russell O'Connor ได้รับการยกย่องว่าเป็นคนแรกที่อธิบายถึงต้นแบบของ MAST และบางแหล่งได้เพิ่ม Pieter Wuille ที่มา: Peter Todd, Gregory Maxwell (อ้างถึงใน Jeremy Rubin และคณะ) และ Mark Friedenbach (ในการสื่อสารส่วนบุคคล)
ขอบคุณ John Newbery
ลิงค์ต้นฉบับ:
(เกิน)
(มีไฮเปอร์ลิงก์มากมายในบทความนี้ คุณสามารถคลิก "อ่านข้อความต้นฉบับ" ที่ด้านล่างซ้ายเพื่อรับจากเว็บไซต์ EthFans)
ลิงค์ต้นฉบับ:
https://bitcointechtalk.com/what-is-a-bitcoin-merklized-abstract-syntax-tree-mast-33fdf2da5e2f
แปล: เจียน
แปล: เจียน
