การแบ่งแยกในระยะที่ 3 ซึ่งเป็นจุดเริ่มต้นของการพัฒนา TAP จะเป็นจุดเริ่มต้นของ Bitcoin ระยะ 2.0 หรือไม่

ผู้เขียนต้นฉบับ: Fu Shaoqing, SatoshiLab, Wanwudao BTC Studio

1. บทนำ

หลังจากที่ฉันเขียนบทความเรื่อง "ความเข้าใจอย่างถ่องแท้เกี่ยวกับเทคโนโลยี Segregated Witness ของ Bitcoin และการอัปเกรดสามเวอร์ชัน" เสร็จ ฉันก็รู้สึกอยากคิดอย่างลึกซึ้ง

นับตั้งแต่เริ่มก่อตั้ง Bitcoin ได้สำรวจทั้งการปรับขนาดและการเพิ่มสมรรถนะ การเกิดขึ้นของ TAP (Taproot Assets Protocol) ได้วางรากฐานทางสถาปัตยกรรมที่แข็งแกร่งและเส้นทางที่เป็นไปได้สำหรับการปรับขนาดและการเพิ่มสมรรถนะของ Bitcoin ปัจจุบัน TAP ช่วยให้ปรับขนาดไปยังพื้นที่ข้อมูลแบบอนันต์ได้ การเพิ่มประสิทธิภาพของพลังงานจะไปถึงอนันต์ได้หรือไม่ กล่าวคือ ความสมบูรณ์แบบทัวริง? เราจะวิเคราะห์เส้นทางทั้งทางทฤษฎีและทางปฏิบัติที่สามารถสำรวจได้ หาก Bitcoin สามารถปรับขนาดและการเพิ่มสมรรถนะได้อย่างสมบูรณ์ ก็จะเกิดสถานการณ์บล็อกเชนที่เป็นหนึ่งเดียว กระบวนการนี้จะดำเนินต่อไปอย่างยาวนาน ท้าทาย และต้องอาศัยภูมิปัญญาและประสบการณ์จริงร่วมกัน เรายินดีต้อนรับผู้ที่สนใจมาร่วมพูดคุยและมีส่วนร่วมในการพัฒนา

2. การกักกันครั้งที่สามเป็นพยานของการเปิดประตูบานใหม่

หากจะเริ่มต้นด้วยข้อสรุปง่ายๆ: ประตูใหม่ที่เปิดโดย Segregated Witness ที่สามคือความพร้อมใช้งานของพื้นที่ข้อมูลแบบไม่มีที่สิ้นสุด ซึ่งช่วยให้สามารถพัฒนาเครื่องเสมือน (VM) ที่สมบูรณ์แบบของทัวริงได้

ก่อนอื่นเรามาทบทวนการเปลี่ยนแปลงสำคัญที่เกิดจากเทคโนโลยี Segregated Witness ครั้งที่ 3 และจากนั้นมาตรวจสอบการพัฒนาต่อไปของ Bitcoin จากมุมมองของโปรโตคอลแบบหลายชั้น

2.1. โปรโตคอล TaprootAssets วางรากฐานอะไรไว้?

ในบทความก่อนหน้าของผม "ความเข้าใจอย่างถ่องแท้เกี่ยวกับเทคโนโลยี Segregated Witness ของ Bitcoin และการอัปเกรดสามเวอร์ชัน" คุณจะเห็นการสำรวจเบื้องต้นของ OP_RETURN และการเปลี่ยนแปลงเวอร์ชันสามเวอร์ชันของ Segregated Witness ที่ตามมา ดูแผนภาพด้านล่าง:

เราจะเห็นการเปลี่ยนแปลงสำคัญสองประการในการอัปเกรดครั้งที่สามของโปรโตคอล Segregated Witness (SegWit):

1. มันได้ถึงขีดจำกัดแล้วในแง่ของการขยายตัว—การใช้พื้นที่ข้อมูลที่ไม่จำกัด

2. สถาปัตยกรรมแยก VM ของ BTCscript ออกจาก VM ของ TAP ซึ่งวางรากฐานสถาปัตยกรรมที่ดีสำหรับการพัฒนาฟีเจอร์ในอนาคต

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

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

2.2 การพัฒนา Bitcoin ต้องใช้แนวทางการออกแบบโปรโตคอลแบบหลายชั้น

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

บทความของผม "ภาพรวมที่ครอบคลุมเกี่ยวกับพื้นฐานของการสร้างเลเยอร์ 2 ของ Bitcoin (V2.0)" ให้คำอธิบายโดยละเอียดยิ่งขึ้นเกี่ยวกับโปรโตคอลแบบเลเยอร์ การออกแบบแบบเลเยอร์เป็นวิธีการและแนวทางที่มนุษย์ใช้ในการจัดการระบบที่ซับซ้อน ด้วยการแบ่งระบบออกเป็นหลายเลเยอร์ และการกำหนดความสัมพันธ์และฟังก์ชันระหว่างแต่ละเลเยอร์ ทำให้ระบบสามารถทำงานแบบโมดูลาร์ บำรุงรักษาได้ และปรับขนาดได้ ซึ่งจะช่วยปรับปรุงประสิทธิภาพและความน่าเชื่อถือในการออกแบบระบบ

ข้อดีของโปรโตคอลแบบหลายชั้น: แต่ละชั้นมีความเป็นอิสระ มีความยืดหยุ่นที่ดี แยกออกจากกันทางโครงสร้างได้ ง่ายต่อการนำไปใช้และบำรุงรักษา และส่งเสริมการสร้างมาตรฐาน

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

Web3.0 ในอนาคต (หรืออาจเรียกได้ว่าเป็นอินเทอร์เน็ตแห่งคุณค่า) จะถูกสร้างขึ้นบนเครือข่ายที่มี Bitcoin เป็นเลเยอร์แรก แนวคิดการออกแบบเลเยอร์ของ Bitcoin ได้เริ่มพัฒนาแล้ว มีตัวอย่างสถาปัตยกรรมเลเยอร์ 2 ที่กำลังศึกษาอยู่หลายแบบ ซึ่งโดยทั่วไปคือเลเยอร์ 2 บนบล็อกเชน และเลเยอร์ 2 บนระบบแบบกระจาย (เช่น Lightning Network) รวมถึงสถาปัตยกรรม RGB บนโปรโตคอล LNP/BP เมื่อ RGB บนโปรโตคอล BP จะเป็นสถาปัตยกรรมเลเยอร์ 2 และเมื่ออิงตามโปรโตคอล LNP จะเป็นสถาปัตยกรรมเลเยอร์ 3

อย่างไรก็ตาม การเปลี่ยนแปลงที่เกิดขึ้นจาก TAP ในครั้งนี้ไม่ได้มีความคล้ายคลึงกับโปรโตคอลแบบเลเยอร์มากนัก เหมือนกับวิวัฒนาการจากเวอร์ชัน 1.0 ไปเป็น 2.0 ของบางสิ่ง ทั้งนี้เนื่องจากโปรโตคอล TAP และเครือข่ายหลักของ Bitcoin มีความคล้ายคลึงและเชื่อมโยงกันอย่างใกล้ชิด ดังแสดงในประเด็นต่อไปนี้:

1. ในแง่ของโครงสร้างข้อมูล TAP ยังใช้โครงสร้าง UTXO เดียวกันกับเมนเน็ต เรียกว่า vUTXO การสร้าง ถ่ายโอน รวม และแยก vUTXO เหล่านี้สอดคล้องกับเมนเน็ตของ Bitcoin และการแลกเปลี่ยนแบบกระจายศูนย์สามารถทำได้ด้วย UTXO ของเมนเน็ต จาก vByte ใน SegWit สู่ vUTXO ใน TAP ถือเป็นการสานต่อและพัฒนาปรัชญาการออกแบบเดียวกัน

2. ในแง่ของประเภทที่อยู่และคำสั่งสคริปต์ที่ดำเนินการ TAP ยังคงมีความคล้ายคลึงกับเมนเน็ตของ Bitcoin อย่างมาก และสถาปัตยกรรมของ TAP ยังเปิดโอกาสให้ขยายได้ ไม่เพียงแต่สามารถกู้คืนคำสั่งที่ถูกทิ้งโดยเมนเน็ตของ Bitcoin เท่านั้น แต่ยังสามารถเพิ่มคำสั่งใหม่ได้ตามต้องการ นอกจากนี้ คำสั่งเหล่านี้ยังดำเนินการภายในเครื่องเสมือน (VM) แยกต่างหากอีกด้วย

3. ใช้โปรโตคอล consensus ของ Bitcoin mainnet แม้ว่า TAP จะมีความก้าวหน้ามากมายในด้านความสามารถในการปรับขนาดและการขยายขีดความสามารถ แต่ก็ไม่ใช่บล็อกเชนอิสระหรือระบบภายนอกที่เป็นอิสระ การเปลี่ยนแปลงทั้งหมดจำเป็นต้องใช้โปรโตคอล consensus ของ Bitcoin mainnet และเป็นส่วนขยายที่ต้องอาศัย Bitcoin mainnet ในการดำเนินการ

ดังนั้น เมื่อออกแบบฟังก์ชันที่เกี่ยวข้องกับ TAP เราจึงใช้ระเบียบวิธีโปรโตคอลแบบเลเยอร์เพื่อพิจารณาโปรโตคอล TAP และจัดการการแบ่งงานภายในองค์กร อย่างไรก็ตาม จากมุมมองของวิวัฒนาการของสรรพสิ่ง เราเชื่อว่าการมองการเปลี่ยนแปลงนี้ว่าเป็นการพัฒนาของ BTC2.0 จะช่วยให้การรักษาความสัมพันธ์ที่ใกล้ชิดและการพึ่งพากันระหว่างทั้งสองง่ายขึ้น และทำให้การประสานงานและจัดสรรทรัพยากรที่จำเป็นสำหรับการพัฒนา BTC2.0 ง่ายขึ้นด้วย

หากเราวิเคราะห์โปรโตคอล RGB จากสามมุมมองข้างต้น เราจะเห็นความแตกต่าง โปรโตคอล RGB ขาดคุณลักษณะข้อ 1 และ 2 อย่างสิ้นเชิง และมีความคล้ายคลึงกันเพียงการใช้โปรโตคอลคอนเซนซัสของเมนเน็ตของ Bitcoin เท่านั้น ซึ่งชี้ให้เห็นว่า RGB เป็นโปรโตคอลแบบหลายชั้น ไม่ใช่เป็นภาคต่อของเมนเน็ตของ Bitcoin

3. BTC 1.0 และ BTC 2.0

การเปลี่ยนแปลงครั้งสำคัญที่เกิดขึ้นจากโปรโตคอล TAP ได้วางรากฐานและจุดเริ่มต้นที่แข็งแกร่งสำหรับการพัฒนา Bitcoin ยุคใหม่ ดังที่การวิเคราะห์ในหัวข้อก่อนหน้านี้แสดงให้เห็น เมนเน็ตของ Bitcoin นั้นขึ้นอยู่กับ TAP อย่างมาก ในบทความนี้ ผมจะยกตัวอย่าง BTC1.0 และ BTC2.0 เพื่อแยกแยะระหว่างเมนเน็ตของ Bitcoin และการขยายตัวและการเปลี่ยนแปลงของเครือข่าย Bitcoin ที่เกิดจากการสร้าง TAP

3.1. คำจำกัดความพื้นฐาน

ในที่นี้ เรานิยาม BTC1.0 ว่าเป็นการพัฒนาบนเครือข่ายหลัก Bitcoin การเปลี่ยนแปลงและการสำรวจทั้งหมดบนเครือข่ายหลัก Bitcoin อยู่ภายใต้ขอบเขตของ BTC1.0 ก่อนการถือกำเนิดของเทคโนโลยี TAP การสำรวจเกือบทั้งหมดล้วนอิงกับ BTC1.0 ซึ่งรวมถึง Bitcoin fork หลายรูปแบบ ซึ่งมีวัตถุประสงค์เพื่อยืนยันความเป็นไปได้บางประการของ BTC1.0 เช่นกัน

BTC2.0 ถูกนิยามว่าเป็นการสำรวจนอกเครือข่ายหลัก (mainnet) ของ Bitcoin โดยเฉพาะอย่างยิ่งโปรโตคอลอย่าง TAP (และอาจมีโปรโตคอลอื่นๆ ที่คล้ายคลึงกันในอนาคต) ขอบเขตนี้ไม่เกี่ยวข้องกับการเปลี่ยนแปลงเครือข่ายหลัก (mainnet) ของ Bitcoin แต่มุ่งเน้นไปที่การสำรวจการปรับขนาดและการเพิ่มขีดความสามารถ (power enhancement) นอกเครือข่ายหลัก (mainnet) ของ Bitcoin เป็นหลัก อย่างไรก็ตาม BTC2.0 ยังคงพึ่งพาโปรโตคอลแบบฉันทามติ (consensus protocol) และคุณสมบัติพื้นฐานของเครือข่ายหลัก (mainnet) ของ Bitcoin อย่างมาก ความสัมพันธ์กับเครือข่ายหลัก (mainnet) ของ Bitcoin นั้นมีความใกล้ชิดกันอย่างมาก ทำให้ยากที่จะแยกออกจากการพัฒนา Bitcoin โดยใช้แนวคิดที่เป็นอิสระ

3.2. วิธีการแยกแยะ

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

หลักการพัฒนาของ BTC2.0 คือการตอบสนองการเปลี่ยนแปลงทั้งหมดที่ต้องการบนเมนเน็ตของ Bitcoin ที่ละเมิดหลักการพัฒนาของ BTC1.0 ตัวอย่างเช่น การขยายคำสั่ง OP_CAT ความปรารถนาที่จะพัฒนาเมนเน็ตของ Bitcoin ให้เป็นระบบ Turing-complete นอกจากนี้ยังสามารถอธิบายได้ว่าเป็นข้อกำหนดด้านการปรับขนาดและการปรับปรุงประสิทธิภาพใดๆ ที่ไม่เหมาะสมสำหรับเมนเน็ตของ Bitcoin ซึ่งสามารถนำไปใช้งานใน BTC2.0 ได้

ในโปรโตคอล TAP อวกาศได้ถูกขยายออกไปสู่อนันต์ผ่านจักรวาลแล้ว เหลือเพียงคำถามว่าควรพัฒนา TAP-VM ให้เป็นระบบทัวริงสมบูรณ์หรือไม่ ในหัวข้อถัดไป เราจะวิเคราะห์ความเป็นไปได้ของการพัฒนา TAP-VM ให้เป็นระบบทัวริงสมบูรณ์ รวมถึงขั้นตอนต่างๆ ที่อาจเกิดขึ้น

หมายเหตุ: TAP เป็นโปรโตคอลแบบสมบูรณ์ ซึ่งรวมถึง TAP-VM ดังนั้นคำว่า TAP จะถูกใช้ในเนื้อหาต่อไปนี้

• ขั้นตอนที่ TAP พัฒนาไปเป็นทัวริงเสร็จสิ้นแล้ว

การกล่าวถึงวิวัฒนาการของ TAP สู่ความสมบูรณ์แบบทัวริงเป็นหัวข้อเฉพาะทางอย่างยิ่ง ซึ่งเกี่ยวข้องกับความรู้พื้นฐานเกี่ยวกับภาษาโปรแกรมและการออกแบบเครื่องเสมือน จากมุมมองของทฤษฎีคอมไพเลอร์และประวัติการพัฒนาคอมไพเลอร์ วิวัฒนาการของเครื่องเสมือน (VM) จากแบบสมบูรณ์ที่ไม่ใช่แบบทัวริงไปเป็นแบบสมบูรณ์แบบทัวริง โดยทั่วไปแล้ว วิวัฒนาการของเครื่องเสมือน (VM) จากแบบง่ายไปแบบซับซ้อน จากแบบปลอดภัยไปแบบทรงพลัง และจากแบบเฉพาะทางไปแบบอเนกประสงค์ (ประโยคนี้จะถูกกล่าวซ้ำหลายครั้งในบทความนี้)

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

หากจำเป็นต้องพัฒนา TAP ให้มีความสมบูรณ์แบบทัวริง จะสามารถปฏิบัติตามกระบวนการและวิธีการใดบ้าง และเรียนรู้จากการพัฒนาดังกล่าวได้

4.1. ความสมบูรณ์ของทัวริงจากมุมมองของหลักการคอมไพเลอร์

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

ในทฤษฎีความสามารถในการคำนวณ ชุดกฎสำหรับการดำเนินการข้อมูล (ชุดคำสั่ง ภาษาโปรแกรม หรือออโตมาตันแบบเซลลูลาร์) ที่ช่วยให้สามารถคำนวณข้อมูลใดๆ ได้ในลำดับที่กำหนด เรียกว่า ทัวริงสมบูรณ์ อุปกรณ์ที่มีชุดคำสั่งทัวริงสมบูรณ์จะถูกนิยามว่าเป็นคอมพิวเตอร์เอนกประสงค์ หากเป็นทัวริงสมบูรณ์ อุปกรณ์นั้น (อุปกรณ์คอมพิวเตอร์) จะสามารถดำเนินการข้ามเงื่อนไข (คำสั่ง "if" และ "goto") และแก้ไขข้อมูลในหน่วยความจำได้ หากสิ่งใดแสดงความสมบูรณ์แบบทัวริง มันสามารถจำลองคอมพิวเตอร์แบบดั้งเดิมได้ และแม้แต่คอมพิวเตอร์ที่เรียบง่ายที่สุดก็สามารถจำลองคอมพิวเตอร์ที่ซับซ้อนที่สุดได้ ภาษาโปรแกรมเอนกประสงค์และชุดคำสั่งทั้งหมดของคอมพิวเตอร์สมัยใหม่ล้วนเป็นทัวริงสมบูรณ์ (เทมเพลต C++ เป็นทัวริงสมบูรณ์) และสามารถแก้ปัญหาหน่วยความจำที่จำกัดได้ เครื่องทัวริงสมบูรณ์ถูกกำหนดให้มีหน่วยความจำไม่จำกัด แต่โดยทั่วไปชุดคำสั่งของพวกมันจะถูกกำหนดให้ทำงานบน RAM ที่มีจำนวนจำกัดเท่านั้น

วิวัฒนาการของเครื่องเสมือน (VM) จากแบบ non-Turing complete ไปเป็นแบบ Turing complete โดยทั่วไปจะเกี่ยวข้องกับกระบวนการที่เพิ่มความซับซ้อน ความปลอดภัย และความสามารถทั่วไป ซึ่งเกี่ยวข้องกับประเด็นหลักสองประการ ได้แก่

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

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

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

4.2. ขั้นตอนที่แตกต่างกันหลายขั้นตอนในการพัฒนา VM จากแบบไม่สมบูรณ์ทัวริงไปจนถึงแบบสมบูรณ์ทัวริง

วิวัฒนาการของเครื่องเสมือน (VM) จากแบบ non-Turing complete ไปเป็นแบบ Turing complete โดยทั่วไปจะเกี่ยวข้องกับกระบวนการที่เพิ่มความซับซ้อน ความปลอดภัย และความสามารถทั่วไป ซึ่งสามารถสรุปได้เป็นขั้นตอนทั่วไปดังต่อไปนี้:

1. เฟสที่ 1: เครื่องคิดเลขแบบบริสุทธิ์ (ไม่ใช่แบบทัวริงสมบูรณ์)

คุณสมบัติ: มีความสามารถในการคำนวณการแสดงออกขั้นพื้นฐานเท่านั้น และไม่มีสถานะและไม่มีการควบคุมการไหล

• ความสามารถ: รองรับการดำเนินการทางคณิตศาสตร์พื้นฐาน (การบวก การลบ การคูณ และการหาร) การดำเนินการเชิงตรรกะ การดำเนินการระดับบิต ฯลฯ ทำงานเหมือนเครื่องคิดเลขขั้นสูง โดยการคำนวณแต่ละครั้งจะเป็นอิสระและไม่ขึ้นอยู่กับสถานะก่อนหน้า
• ภาวะไร้รัฐ: ไม่มีแนวคิดเรื่องหน่วยความจำ หรือหน่วยความจำเป็นแบบอ่านอย่างเดียวและไม่สามารถแก้ไขได้ ไม่สามารถกำหนดหรือแก้ไขตัวแปรได้
• ไม่มีโฟลว์ควบคุม: ไม่มีเงื่อนไขแบบแยกสาขา (if/else), ลูป (for/while) หรือคำสั่ง jump คำสั่งสามารถดำเนินการได้ตามลำดับเท่านั้น
• เหตุใดจึงไม่ใช่ทัวริงสมบูรณ์: ไม่สามารถใช้ลูปหรือการตัดสินแบบมีเงื่อนไขได้ และไม่สามารถจำลองเทปกระดาษที่ยาวไม่สิ้นสุดและการเปลี่ยนสถานะของเครื่องทัวริงได้
• ตัวอย่างทางประวัติศาสตร์: เครื่องมือประเมินการกำหนดค่าหรือการแสดงออกที่เรียบง่ายที่สุดในยุคแรกๆ

2. ระยะที่สอง: การแนะนำสาขาสถานะและเงื่อนไข (ขั้นตอนสำคัญสู่ความสมบูรณ์)

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

ความสามารถ:

(1) สถานะ: นำเสนอหน่วยความจำที่อ่านและเขียนได้ (เช่น สแต็ก รีจิสเตอร์ ฮีป) ซึ่งช่วยให้สามารถกำหนดและแก้ไขตัวแปรได้ ซึ่งทำให้การคำนวณขึ้นอยู่กับประวัติ แทนที่จะแยกออกจากกัน

(2) การแยกสาขาแบบมีเงื่อนไข: การดำเนินการนี้จะแนะนำคำสั่งการข้ามตามเงื่อนไข (เช่น if_eq, if_lt, jmp ไปยังออฟเซ็ตที่ระบุ) ซึ่งเป็นสิ่งสำคัญในการนำการตัดสินเชิงตรรกะไปใช้

• เหตุใดจึงอาจยังไม่สมบูรณ์แบบทัวริง: หากชุดคำสั่งหรือการออกแบบของ VM ตั้งใจห้ามการกระโดดย้อนกลับ นั่นคือ มันสามารถกระโดดไปยังคำสั่งถัดไปได้เท่านั้น (การกระโดดไปข้างหน้า) จะไม่สามารถสร้างลูปได้ หากไม่มีลูป ศักยภาพของ "การคำนวณแบบอนันต์" ที่จำเป็นสำหรับความสมบูรณ์แบบทัวริงก็จะไม่สามารถเกิดขึ้นได้ (แม้ว่าในเชิงฟิสิกส์จะมีจำกัด แต่ในทางทฤษฎีแล้วจะเป็นอนันต์)
• ตัวอย่างทางประวัติศาสตร์/สมัยใหม่: Bitcoin Script ซึ่งเป็นภาษาสคริปต์ เป็นตัวอย่างคลาสสิกตั้งแต่ยุคแรกเริ่ม มันถูกออกแบบอย่างจงใจให้ปราศจากการวนซ้ำ มีเพียงการแยกสาขาแบบมีเงื่อนไขและการกระโดดไปข้างหน้า เพื่อป้องกันไม่ให้การวนซ้ำไม่สิ้นสุดปิดกั้นเครือข่าย จึงมั่นใจได้ว่าสคริปต์จะทำงานเสร็จสิ้นภายในจำนวนขั้นตอนที่จำกัด

หมายเหตุ: โดยส่วนตัวแล้ว ผมเชื่อว่าภาษาสคริปต์ของ Bitcoin ทำงานหลักในเฟส 1 โดยมีสัดส่วนเล็กน้อยที่แสดงลักษณะเฉพาะของเฟส 2 โดยคร่าวๆ แล้ว เฟส 1 คิดเป็นสัดส่วนมากกว่า 90% และเฟส 2 น้อยกว่า 10% ยกตัวอย่างเช่น MAST (Merkel Abstract Syntax Tree) ซึ่งต่อมาได้เพิ่มเข้ามาใน Taproot นั้น ทำงานได้ไม่ดีนักบนเมนเน็ตของ Bitcoin แต่มีบทบาทสำคัญใน TAP เหตุผลสำคัญประการหนึ่งก็คือ เมนเน็ตของ Bitcoin มีเป้าหมายที่จะรักษาเครื่องเสมือนให้อยู่ในขีดความสามารถของเฟส 1

3. ขั้นตอนที่สาม: แนะนำลูปหรือการเรียกซ้ำ (เพื่อให้บรรลุความสมบูรณ์ของทัวริง)

คุณสมบัติ: มีความสามารถในการสร้างโครงสร้างแบบลูป

ความสามารถ:

(1) การกระโดดย้อนกลับ: อนุญาตให้คำสั่งกระโดดย้อนกลับไปยังที่อยู่คำสั่งก่อนหน้า ซึ่งสามารถสร้างลูปได้โดยตรง

(2) คำสั่งวนซ้ำ: จัดทำคำสั่งวนซ้ำเฉพาะ (เช่น วนซ้ำ)

(3) การกระโดดทางอ้อม/การเรียกใช้ฟังก์ชัน: ด้วยการรองรับการเรียกใช้ฟังก์ชันและการเรียกซ้ำ ทำให้เกิดเอฟเฟกต์ลูปแบบเดียวกันได้ เนื่องจากการเรียกซ้ำสามารถแทนที่ลูปได้อย่างเท่าเทียมกัน

• เหตุใดทัวริงจึงเสร็จสมบูรณ์ ณ จุดนี้? เมื่อทัวริงสามารถดำเนินการแตกแขนงแบบมีเงื่อนไข (conditional branching) และการกระโดด/วนซ้ำแบบย้อนกลับ (backward jumps/loops/recursion) ได้แล้ว VM นี้ก็จะสามารถประมวลผลการตัดสินแบบมีเงื่อนไข (conditional judgment) และการประมวลผลซ้ำได้ ในทางทฤษฎี การผสมผสานสองสิ่งนี้เข้าด้วยกัน ช่วยให้ทัวริงสามารถจำลองกระบวนการคำนวณของเครื่องทัวริงใดๆ ก็ได้ จึงบรรลุความสมบูรณ์แบบทัวริง
• ตัวอย่างทางประวัติศาสตร์: เครื่องเสมือนสำหรับภาษาโปรแกรมเอนกประสงค์เกือบทั้งหมด (เช่น JVM, Python VM และ .NET CLR) ล้วนใช้ระบบทัวริงตั้งแต่เริ่มแรก เนื่องจากถูกออกแบบมาเพื่อรันภาษาโปรแกรมเอนกประสงค์ วิวัฒนาการของเครื่องเสมือนมุ่งเน้นไปที่การเพิ่มประสิทธิภาพและคุณสมบัติด้านความปลอดภัยเป็นหลัก

4. ขั้นตอนที่สี่: การปรับปรุงตามความสมบูรณ์ของทัวริง (ความปลอดภัย ประสิทธิภาพ คุณสมบัติ)

เมื่อบรรลุความสมบูรณ์ของทัวริงแล้ว จุดเน้นของการพัฒนา VM จะไม่อยู่ที่พลังการประมวลผลอีกต่อไป แต่จะอยู่ที่ด้านอื่นๆ:

• ประสิทธิภาพ: นำเสนอการคอมไพล์แบบ JIT (Just-In-Time) การคอมไพล์แบบ AOT (Ahead-of-Time) คอมไพเลอร์ที่ได้รับการปรับให้เหมาะสม และอัลกอริธึมการรวบรวมขยะที่มีประสิทธิภาพมากขึ้น
• ความปลอดภัย: กลไกแซนด์บ็อกซ์ที่ได้รับการปรับปรุง การนำระบบความสามารถมาใช้ และการแยกและควบคุมหน่วยความจำที่ละเอียดยิ่งขึ้น WebAssembly เป็นตัวอย่างที่ยอดเยี่ยมในยุคปัจจุบัน มอบความสามารถแบบทัวริงที่สมบูรณ์ ขณะเดียวกันก็เพิ่มความปลอดภัยและการกำหนดความแน่นอนอย่างมีนัยสำคัญ ผ่านหน่วยความจำเชิงเส้น การควบคุมการไหลแบบมีโครงสร้าง และสภาพแวดล้อมแซนด์บ็อกซ์
• คุณสมบัติ: รองรับคุณสมบัติภาษาขั้นสูง เช่น coroutines, async/await, generics และการสะท้อนกลับ
• การกำหนดล่วงหน้า: สำหรับเครื่องเสมือนบล็อคเชนบางเครื่อง (เช่น เครื่องที่สืบทอดมาจาก Ethereum EVM) โดยอาศัยความสมบูรณ์ของทัวริง การแสวงหาการกำหนดล่วงหน้า (ผลลัพธ์ที่สอดคล้องกันในโหนดทั้งหมด) และการยุติ (การจำกัดขั้นตอนการดำเนินการจริงผ่านกลไก Gas) จะกลายเป็นจุดเน้น

จากมุมมองของหลักการคอมไพเลอร์ เราจะเห็นสี่ขั้นตอนในการพัฒนา VM เมื่อพิจารณาเส้นทางการพัฒนานี้ เรายังเห็นคร่าวๆ ว่ามีหลายขั้นตอนในการพัฒนา TAP (นั่นคือหลายขั้นตอนในการพัฒนา BTC2.0)

4.3. เฟสแรกของ TAP: การสำรวจเบื้องต้นของคำสั่ง BTCScript ที่ขยายออกไป

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

เนื่องจาก TAP เป็นจุดเริ่มต้นของ BTC 2.0 จากมุมมองของการแยกเฟสหลักการคอมไพเลอร์ TAP-VM ในปัจจุบันควรพัฒนาไปสู่ขั้นที่สองของ VM อเนกประสงค์ เมื่อสำรวจขั้นนี้ TAP-VM สามารถขยายคำสั่ง BTCScript ได้อย่างเหมาะสม โดยกู้คืนคำสั่ง BTCScript ที่ถูกลบไปก่อนหน้านี้ เช่น ค่อยๆ เพิ่มคำสั่งที่คาดการณ์ไว้อย่างกว้างขวาง เช่น OP_CAT แต่ละคำสั่งที่เพิ่มเข้ามาต้องใช้แอปพลิเคชันเพิ่มเติมเพื่อทดสอบการทำงานและความปลอดภัย ขั้นนี้สามารถดำเนินการอย่างง่าย เช่น TrustlessSwap นอกจากนี้ยังสามารถเพิ่มกรณีการใช้งานของเทคโนโลยี Taproot เช่น การใช้ MAST tree ที่หลากหลายยิ่งขึ้น

ขั้นตอนนี้ควรครอบคลุมฟังก์ชันพื้นฐานของ BTCFi เช่น การซื้อขายแบบกระจายศูนย์ การกู้ยืมขั้นพื้นฐาน และการ Staking ขั้นพื้นฐาน ปัจจุบัน ฟังก์ชันเหล่านี้สามารถทำได้ผ่าน TrustlessSwap และบางส่วนของ Tapscript

4.4. ระยะที่สองของ TAP: การสร้างชุดคำสั่ง BTCFi แบบกระจายอำนาจ

การพัฒนา TAP-VM เพื่อรองรับแอปพลิเคชันทางการเงินส่วนใหญ่จำเป็นต้องได้รับคำสั่งเพิ่มเติมที่จำเป็นจากทั้งหลักการคอมไพเลอร์และมุมมองของแอปพลิเคชัน อย่างไรก็ตาม ขั้นตอนนี้ไม่จำเป็นต้องเสร็จสมบูรณ์ตามหลักทัวริง ขั้นตอนนี้จำเป็นต้องรองรับแอปพลิเคชัน BTCFi ทั่วไป เช่น การให้กู้ยืม การสเตคกิ้ง Mint StableCoin และฟังก์ชันสวอปที่ซับซ้อนยิ่งขึ้น

ขั้นตอนนี้ใกล้เคียงกับขั้นตอนที่สองของ VM ทั่วไปมาก ซึ่งจำเป็นต้องมีการนำสาขาสถานะและสาขาเงื่อนไขมาใช้ สาขาสถานะและสาขาเงื่อนไขเหล่านี้ถูกนำไปใช้ในโครงสร้างไวยากรณ์เชิงนามธรรมของ MAST แม้ว่าจะมีโครงสร้าง MAST อยู่แล้วในเทคโนโลยี Taproot ของ BTC 1.0 แต่คำสั่งเงื่อนไขเหล่านี้จะสามารถทำงานได้อย่างมีประสิทธิภาพมากขึ้นก็ต่อเมื่อ BTC-VM ของเครือข่ายหลัก Bitcoin ถูกแยกออกจาก TAP-VM อิสระ

4.5 ขั้นตอนที่สามของ TAP: ชุดคำสั่งที่สมบูรณ์ยิ่งขึ้นและความสมบูรณ์ของทัวริงเบื้องต้น

วิวัฒนาการของ TAP-VM เพื่อรองรับแอปพลิเคชันที่ซับซ้อนยิ่งขึ้น นอกเหนือจากแอปพลิเคชันทางการเงิน ขึ้นอยู่กับแรงผลักดันของแอปพลิเคชันที่มีต่อ TAP-VM ขั้นตอนนี้จะค่อยๆ เข้าใกล้ความสมบูรณ์ของทัวริง หรือความสมบูรณ์เบื้องต้นของทัวริง

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

แม้ว่า TAP-VM จะพัฒนาจนมีความสมบูรณ์แบบทัวริงในขั้นตอนนี้ แต่ก็ยังมีความแตกต่างอย่างมากจากความสมบูรณ์แบบทัวริงของ RGB การเปรียบเทียบนี้คล้ายกับการเปรียบเทียบภาษา C++ และ Java เราจะมีการเปรียบเทียบโดยละเอียดเพิ่มเติมในหัวข้อ 5.1

4.6 ขั้นตอนที่สี่ของ TAP: ความสมบูรณ์ของทัวริง + ไลบรารีที่สมบูรณ์

ในขั้นตอนการพัฒนานี้ TAP-VM ไม่เพียงแต่บรรลุความสมบูรณ์ของทัวริงเท่านั้น แต่ยังเริ่มมีชุดไลบรารีคลาส (หรือไลบรารีฟังก์ชัน) มากมาย ซึ่งในทางทฤษฎีแล้วสามารถเติมเต็มฟังก์ชันแอปพลิเคชันทั้งหมดได้ และมีตัวอย่างแอปพลิเคชันจำนวนมากพอสมควร ด้วยตัวอย่างแอปพลิเคชันที่หลากหลายและการรองรับไลบรารีคลาส นักพัฒนาจึงสามารถพัฒนาแอปพลิเคชันจำนวนมากได้ง่ายขึ้น

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

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

5. ระบบทัวริงสมบูรณ์ยังมีสถานการณ์การใช้งานที่แตกต่างกัน

ในระบบนิเวศ BTC เราอ้างอิงการเปรียบเทียบระบบทัวริงสมบูรณ์สองระบบ ได้แก่ TAP และ RGB เพื่อแสดงให้เห็นว่าระบบใดเหมาะสมกับสถานการณ์การใช้งานที่แตกต่างกัน หรือดีกว่านั้น คือการแสดงให้เห็นสถานการณ์การใช้งานของ TAP

จากประสบการณ์ในโดเมน Web2 และข้อมูลมากมายเกี่ยวกับเครื่องเสมือน (VM) ทำให้สามารถเปรียบเทียบภาษาพัฒนา C/C++ + สภาพแวดล้อมรันไทม์กับภาษาพัฒนา Java + สภาพแวดล้อมรันไทม์ได้เป็นอย่างดี การเปรียบเทียบนี้คล้ายกับการเปรียบเทียบระหว่าง TAP และ RGB ซึ่งให้ข้อมูลเชิงลึกที่มีค่า

5.1. การเปรียบเทียบสถานการณ์การใช้งานระหว่าง C/C++ และ Java

ตารางเปรียบเทียบคุณสมบัติหลัก

สรุปสถานการณ์การใช้งาน

1. โดเมนของ C/C++ (ต้องใช้การจัดการฮาร์ดแวร์โดยตรงหรือประสิทธิภาพสูงสุด)

(1) การพัฒนาซอฟต์แวร์/โครงสร้างพื้นฐานระดับระบบ

• ระบบปฏิบัติการ (เช่น Linux, เคอร์เนล Windows)
• ระบบจัดการฐานข้อมูล (เช่น MySQL, PostgreSQL)
• คอมไพเลอร์/อินเทอร์พรีเตอร์ (เช่น GCC และ JVM) จริงๆ แล้วเขียนด้วย C++
• เฟรมเวิร์กเซิร์ฟเวอร์เว็บ/เครือข่ายประสิทธิภาพสูง (เช่น Nginx, เลเยอร์พื้นฐานของ Node.js)

(2) ไดรเวอร์ฮาร์ดแวร์และระบบฝังตัว

• ไดรเวอร์อุปกรณ์: ต้องมีปฏิสัมพันธ์โดยตรงกับรีจิสเตอร์ฮาร์ดแวร์
• อุปกรณ์ฝังตัว/อินเทอร์เน็ตของสรรพสิ่ง (IoT): อุปกรณ์เหล่านี้มีทรัพยากรที่จำกัดมาก (เช่น ไมโครคอนโทรลเลอร์, MCU) ต้องมีการควบคุมหน่วยความจำและการใช้พลังงานอย่างแม่นยำ และไม่สามารถรองรับค่าใช้จ่ายของ JVM ได้

(3) การประมวลผลประสิทธิภาพสูงและการพัฒนาเกม

• เอ็นจิ้นเกม (เช่น ระบบพื้นฐานของ Unreal และ Unity) จำเป็นต้องใช้ประสิทธิภาพของฮาร์ดแวร์อย่างเต็มที่เพื่อดำเนินการคำนวณกราฟิกและฟิสิกส์ที่ซับซ้อน
• ระบบการคำนวณทางวิทยาศาสตร์/การซื้อขายทางการเงิน: แม้แต่ความหน่วงระดับไมโครวินาทีก็มีความสำคัญ
• การประมวลผลกราฟิก/ภาพ/เสียง/วิดีโอ เช่น Photoshop, FFmpeg

(4) สถานการณ์ที่ต้องมีการควบคุมหน่วยความจำและทรัพยากรอย่างละเอียด

ในบางสถานการณ์ การจัดการหน่วยความจำด้วยตนเองนั้นคาดเดาได้มากกว่าการรวบรวมขยะ และสามารถหลีกเลี่ยงความหน่วงที่เกิดจาก GC ได้

2. บ้านเกิดของ Java (ต้องการประสิทธิภาพการพัฒนาสูง ความเข้ากันได้ข้ามแพลตฟอร์ม และความน่าเชื่อถือระดับองค์กร)

(1) การพัฒนาแบ็กเอนด์สำหรับแอปพลิเคชันองค์กรขนาดใหญ่

• แบ็กเอนด์แอปพลิเคชันเว็บ: เฟรมเวิร์ก Spring Boot เป็นผู้นำในด้านการพัฒนาองค์กรของ Java ซึ่งใช้ในการสร้างบริการแบ็กเอนด์แบบกระจายขนาดใหญ่และทำงานพร้อมกันได้สูง
• สถาปัตยกรรมไมโครเซอร์วิส: เฟรมเวิร์กไมโครเซอร์วิสจำนวนมากที่ใช้ Java และ JVM (เช่น Spring Cloud)
• ระบบแบบกระจาย: เช่น Hadoop และ Kafka ในด้านข้อมูลขนาดใหญ่

(2) การพัฒนาแอปพลิเคชัน Android

ภาษาที่เป็นทางการในประวัติศาสตร์ที่ Android เลือกใช้ (แม้ว่า Kotlin จะเป็นภาษาที่เลือกใช้ในปัจจุบัน แต่โค้ดพื้นฐานและระบบนิเวศจำนวนมากยังคงเป็น Java)

(3) บิ๊กดาต้าและคลาวด์คอมพิวติ้ง

ส่วนประกอบหลักของกรอบการทำงานการประมวลผลข้อมูลขนาดใหญ่ เช่น Hadoop, Spark และ Flink ส่วนใหญ่เขียนด้วย Java หรือ Scala (ภาษา JVM)

(4) ระบบที่ต้องการความน่าเชื่อถือสูงและมีอายุการใช้งานยาวนาน

สำหรับระบบหลัก เช่น ธนาคาร การเงิน และอีคอมเมิร์ซ ความแข็งแกร่ง ความปลอดภัย และการสนับสนุนระบบนิเวศชุมชนที่แข็งแกร่งถือเป็นสิ่งสำคัญ

(5) แอปพลิเคชันเดสก์ท็อปข้ามแพลตฟอร์ม

แม้ว่าจะไม่ได้รับความนิยมเท่ากับเว็บ แต่ Swing/JavaFX ยังสามารถนำไปใช้พัฒนาโปรแกรม GUI ข้ามแพลตฟอร์มได้

3.จะเลือกอย่างไร?

• เมื่อเลือก C/C++:

ประสิทธิภาพคือสิ่งสำคัญที่สุด (เกม, ระบบการซื้อขาย)

คุณต้องโต้ตอบโดยตรงกับระบบปฏิบัติการหรือฮาร์ดแวร์ (ไดรเวอร์, ระบบฝังตัว)

ทรัพยากรมีจำกัดมากและไม่สามารถทนต่อหน่วยความจำและ CPU ของ JVM ได้

คุณต้องควบคุมพฤติกรรมของโปรแกรมอย่างสมบูรณ์ (เค้าโครงหน่วยความจำ, กระแสการทำงาน)

• เมื่อเลือก Java:

คุณต้องพัฒนาแอปพลิเคชันองค์กรขนาดใหญ่และซับซ้อน (แบ็กเอนด์เว็บ, ไมโครเซอร์วิส)

ประสิทธิภาพการพัฒนา ความสามารถในการบำรุงรักษา และการทำงานเป็นทีมมีความสำคัญมากกว่าประสิทธิภาพสูงสุด

คุณต้องมีความสามารถในการรองรับหลายแพลตฟอร์มที่แข็งแกร่งและไม่ต้องการคอมไพล์แยกกันสำหรับแต่ละแพลตฟอร์ม

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

โครงการนี้ต้องมีความน่าเชื่อถือสูงและการดำเนินงานที่เสถียรในระยะยาว

โดยสรุป: C/C++ เหมาะกับการทำงานในระดับที่ต่ำกว่า เช่น ชั้นฮาร์ดแวร์หรือระบบปฏิบัติการ ส่วน Java เหมาะกับการทำงานในระดับธุรกิจและแอปพลิเคชัน

5.2. การเปรียบเทียบสถานการณ์การใช้งานระหว่าง TAP และ RGB

ตารางเปรียบเทียบคุณสมบัติหลัก (ผมหวังว่าจะค่อยๆ ปรับปรุงตารางเปรียบเทียบนี้ด้วยความช่วยเหลือจากทุกคนในอนาคต)

สรุปสถานการณ์การใช้งาน (ต่อไปนี้เป็นเพียงการคาดเดาตามลักษณะเฉพาะ เนื่องจาก TAP-VM ยังไม่ได้รับการพัฒนาอย่างเต็มที่ และยังไม่มีกรณีการใช้งานสำหรับ RGB มากนัก)

1. บ้านเกิดของ TAP (ต้องใช้ฟังก์ชันพื้นฐานคล้าย Bitcoin)

(1) การออกสินทรัพย์ในรูปแบบเงินสด

(2) BTCFi บนเครือข่าย Bitcoin

(3) โปรโตคอลพื้นฐานแบบกระจายอำนาจ

2. สนามหญ้าบ้านของ RGB (เหมาะสำหรับ Dapp เกือบทุกประเภท)

(1) แอปพลิเคชันสัญญาอัจฉริยะบนเครือข่าย Bitcoin

(2) การออกสินทรัพย์ขั้นสูงและแอปพลิเคชัน DeFi ที่ซับซ้อนยิ่งขึ้น

(3) แอปพลิเคชัน web3 ระดับสูง เช่น การระบุตัวตนแบบกระจายอำนาจและการกำกับดูแล DAO

(4) แอปพลิเคชัน web3 อื่นๆ ที่กว้างขึ้น

3.จะเลือกอย่างไร?

• เลือก TAP-VM:

การโต้ตอบโดยตรงกับ Bitcoin UTXO

การออกสินทรัพย์ในรูปแบบเงินสด

ขยายฟังก์ชันการทำงานของประเภทสคริปต์ Bitcoin โดยตรง

แอปพลิเคชั่นทางการเงิน Bitcoin แบบกระจายอำนาจ

• เลือก RGB:

สัญญาอัจฉริยะที่ต้องใช้ตรรกะที่ซับซ้อน

DeFi ขั้นสูงและซับซ้อนยิ่งขึ้น

แอปพลิเคชัน Web3 ที่ไม่ใช่ทางการเงิน

โดยสรุป: TAP-VM นั้นใกล้เคียงกับแอปพลิเคชันบน Bitcoin mainnet หรือส่วนขยายโดยตรงของแอปพลิเคชันที่อิงตาม Bitcoin mainnet มากกว่า ส่วน RGB นั้นเหมาะสำหรับแอปพลิเคชันที่มีฟังก์ชันลอจิกที่ซับซ้อนซึ่งอยู่ใกล้กับเลเยอร์ผู้ใช้มากกว่า

6. เราจะพัฒนา BTC 2.0 ได้ดีขึ้นอย่างไร?

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

จากการอภิปรายข้างต้น หากเราสามารถแบ่ง Bitcoin ออกเป็น BTC1.0 และ BTC2.0 ได้ ก็จะนำมาซึ่งข้อได้เปรียบที่ชัดเจนบางประการ

6.1. การแบ่งงานที่ชัดเจนและขั้นตอนมาตรฐาน

ข้อดีอีกประการหนึ่งของการแบ่งงานแบบเป็นขั้นตอนคือช่วยชี้แจงการแบ่งงานและความรับผิดชอบให้ชัดเจนยิ่งขึ้น

1. ด้วยหลักการที่ได้รับการยอมรับสำหรับการตัดสินและการตัดสินใจ ทำให้นักออกแบบสามารถรวมฟีเจอร์ที่สอดคล้องกับหลักการ BTC 1.0 เข้ากับเครือข่ายหลัก Bitcoin และฟีเจอร์ที่สอดคล้องกับหลักการออกแบบ BTC 2.0 เข้ากับโปรโตคอล TAP ได้ง่ายขึ้น ซึ่งไม่เพียงช่วยลดข้อพิพาท แต่ยังส่งเสริมความร่วมมือระหว่างองค์กรให้ดียิ่งขึ้นอีกด้วย

BTC2.0 ยังสามารถอ้างอิงถึงหลักการคอมไพเลอร์และกระบวนการพัฒนาผลิตภัณฑ์อื่นๆ ที่ครบถ้วนเพื่อสร้างแผนขั้นตอนการพัฒนา TAP ที่ชัดเจนยิ่งขึ้น

2. โปรโตคอลและมาตรฐานบางอย่างสามารถตั้งชื่อได้ดีกว่าและมีการกำหนดเกณฑ์การตรวจสอบไว้ ตัวอย่างเช่น โปรโตคอลทั้งเจ็ดของ TAP ปัจจุบันมีชื่อดังต่อไปนี้:

• BIP-TAP-ADDR: ร่างที่อยู่สินทรัพย์บนเชน Taproot
• BIP-TAP-MS-SMT：Merkle Sum Sparse Merkle Trees Draft
• BIP-TAP-PROOF: รูปแบบไฟล์หลักฐานแบบแบนของสินทรัพย์ Tproot
• BIP-TAP-PSBT：ร่าง PSBT สินทรัพย์ Tproot
• BIP-TAP-UNIVERSE: ร่างจักรวาลสินทรัพย์ Taproot
• BIP-TAP-VM: ร่างสคริปต์สินทรัพย์ Taproot v1
• BIP-TAP：TAP: ร่างโปรโตคอลสินทรัพย์ Taproot

หากทุกคนยอมรับวิธีการจำแนกประเภท BTC2.0 ก็สามารถตั้งชื่อโดยเริ่มจาก BIP2 ได้อย่างแน่นอน:

• BIP2: ร่างที่อยู่ Taproot Asset On Chain
• BIP2: TAP Merkle Sum Sparse Merkle Trees Draft
• BIP2: ร่างรูปแบบหลักฐานไฟล์แบนของสินทรัพย์ Taproot
• BIP2: ร่าง PSBT สินทรัพย์ Taproot
• BIP2: ร่างจักรวาลสินทรัพย์ Taproot
• BIP2: ร่างสคริปต์สินทรัพย์ Taproot v1
• BIP2: TAP: ร่างโปรโตคอลสินทรัพย์ Taproot

6.2. การบูรณาการทรัพยากรและการวางแผนการปรับโครงสร้างใหม่

ปัจจุบัน เมนเน็ตของ Bitcoin ได้รับการจัดการหลักโดยทีมงาน Bitcoin Core (ณ เดือนมิถุนายน 2568 เครือข่ายทั้งหมด 90% ใช้ Bitcoin Core) โปรโตคอล TAP ได้รับการจัดการโดย Lightning Network Labs

ซอฟต์แวร์ Bitcoin Core ใช้งานมานานกว่า 15 ปี และฟังก์ชันหลักค่อนข้างเสถียร ไม่น่าจะมีสถานการณ์ที่ต้องเพิ่มฟีเจอร์สำคัญๆ ในอนาคต หรือหากจำเป็นต้องมีการปรับเปลี่ยนครั้งใหญ่ โปรโตคอล TAP ก็มีแนวโน้มที่จะเกิดขึ้น โปรโตคอล TAP ยังอยู่ในช่วงเริ่มต้นของการพัฒนา และหากทุกอย่างเป็นไปตามแผน ย่อมต้องใช้เวลาในการพัฒนาอีกมาก การนำทรัพยากรการพัฒนาที่มีอยู่กลับมาใช้ใหม่อย่างมีประสิทธิภาพจะช่วยส่งเสริมการพัฒนา BTC 2.0 อย่างมาก ที่สำคัญกว่านั้น นักพัฒนาเมนเน็ตของ Bitcoin มีความคล้ายคลึงกับการพัฒนา TAP อย่างมาก ทั้งในด้านสภาพแวดล้อมการพัฒนาและภาษาโปรแกรม ความแตกต่างหลักอยู่ที่แนวทางการพัฒนาที่เปลี่ยนแปลงไป

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

หาก TAP จะต้องพัฒนาเป็น BTC 2.0 จริงๆ แล้ว โปรเจกต์ Bitcoin mainnet (BTC 1.0), BTC 2.0 ใหม่ และ Lightning Network จะเป็นสามโปรเจกต์ที่ค่อนข้างเป็นอิสระแต่มีความเชื่อมโยงกันอย่างใกล้ชิด BTC 2.0 จะมีการบูรณาการเชิงฟังก์ชันที่ลึกซึ้งยิ่งขึ้นกับ Lightning Network และจากฟีเจอร์ใหม่ของ BTC 2.0 Lightning Network ก็จะมีการพัฒนาที่มากขึ้นเช่นกัน

6.3. การพัฒนาและการแข่งขัน

ส่วนที่ 5 ได้อธิบายถึงคุณลักษณะบางประการของ TAP เมื่อเปรียบเทียบกับคู่แข่งโดยตรง ซึ่งสามารถมองได้ว่าเป็นการเปรียบเทียบระหว่าง BTC 2.0 กับโปรโตคอลแบบเลเยอร์ภายนอก ในขั้นตอนการพัฒนาปัจจุบัน RGB และ TAP จะต้องเผชิญกับการแข่งขันโดยตรงอย่างมีนัยสำคัญในหลายด้าน ได้แก่ การออกสินทรัพย์ การซื้อขายสินทรัพย์ และระบบนิเวศ BTCFi ที่กว้างขึ้น แม้ว่า TAP จะมีประสิทธิภาพเหนือกว่าโปรโตคอลหลายตัวในด้านที่ใกล้ชิดกับเครือข่ายหลัก Bitcoin แต่หาก TAP ไม่สามารถพัฒนาเฟส 1 ให้เสร็จสมบูรณ์ได้อย่างรวดเร็ว RGB ที่ใช้ Turing จะกลายเป็นผู้นำในด้านนี้ก่อน การที่ RGB พึ่งพาโปรโตคอลคอนเซนซัสของเครือข่ายหลัก Bitcoin เพียงอย่างเดียวก็เพียงพอที่จะดึงดูดผู้ที่ชื่นชอบ Bitcoin จำนวนมาก เนื่องจากฟังก์ชันการทำงานของมันมีความน่าสนใจมากกว่า หาก TAP ไม่สามารถพัฒนาให้เสร็จสมบูรณ์หรือล่าช้าในการพัฒนาเฟส 2 ก็จะตามหลัง RGB เช่นกัน

TAP จะพัฒนาเป็น BTC 2.0 หรือไม่? กระบวนการพัฒนาจะเป็นอย่างไร? รูปแบบสุดท้ายของมันขึ้นอยู่กับปัจจัยภายนอกหลายประการ การพัฒนาที่อาจเกิดขึ้นเหล่านี้ในพื้นที่ Bitcoin เต็มไปด้วยจินตนาการและความท้าทาย แต่ไม่ว่าจะผ่านกระบวนการใด TAP ก็ได้เปิดประตูสู่เรา

สรุป: หาก TAP แสดงถึงการพัฒนาของ BTC 2.0 แล้วชื่อ TaprootAssets Protocol ก็คงดูเฉพาะเจาะจงและสะท้อนถึงปัจจุบันมากเกินไปใช่ไหมครับ? ไม่ควรอัปเกรดเป็นชื่ออื่นเพื่อให้สะท้อนถึงการพัฒนาของ BTC 2.0 ได้ดียิ่งขึ้นหรือครับ?

อ้างอิง

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

ส่วนที่เกี่ยวกับหลักการคอมไพเลอร์อ้างอิงเนื้อหาจากตำราเรียนหลักสูตรวิทยาการคอมพิวเตอร์ของมหาวิทยาลัย รวมถึงบทความออนไลน์ที่กระจัดกระจาย

บทความอื่นที่เกี่ยวข้องมีดังต่อไปนี้:

1. https://github.com/Roasbeef/bips/blob/bip-tap/bip-tap.mediawiki 7 โปรโตคอลที่เกี่ยวข้องกับ Taproot Assets Protocol

2. ความเข้าใจอย่างถ่องแท้เกี่ยวกับเทคโนโลยี Segregated Witness ของ Bitcoin และการอัปเกรดเวอร์ชันทั้งสาม

3. "ภาพรวมที่ครอบคลุมเกี่ยวกับพื้นฐานของการสร้าง Bitcoin Layer 2 (V2.0)"