การโอนแบบ Off-Chain: เส้นทางวิวัฒนาการของโปรโตคอลสินทรัพย์ Bitcoin

กลางJan 29, 2024
บทความนี้จะแนะนำทิศทางหลักสองประการของความสามารถในการปรับขนาดของ Bitcoin โดยการวิเคราะห์วิวัฒนาการของ Lightning Network และ RGB
การโอนแบบ Off-Chain: เส้นทางวิวัฒนาการของโปรโตคอลสินทรัพย์ Bitcoin

แนะนำสกุลเงิน

การออกสินทรัพย์ตาม BTC ถือเป็นประเด็นร้อนมาโดยตลอด จากการปรากฏตัวครั้งแรกของ Colored Coins ในปี 2011 ไปจนถึง Ordinal Protocol ที่ได้รับความนิยมเมื่อเร็ว ๆ นี้ ชุมชน BTC สามารถนำผู้เล่นใหม่ ๆ ออกมาและเป็นเอกฉันท์ได้เสมอ อย่างไรก็ตาม มีเพียงไม่กี่คนที่ผ่านการทดสอบของกาลเวลา ด้วย Lightling Labs ผู้ทะเยอทะยานที่ประกาศแผนการของพวกเขาในการสร้าง Stable Coin บน Taproot Assets และ Tether ได้ประกาศตัวเลือก RGB สำหรับการสร้างเหรียญ USDT บนเลเยอร์แรกของ Bitcoin เป็นที่ชัดเจนว่า OmniLayer (Mastercoin) ที่ครั้งหนึ่งเคยโด่งดังไม่ใช่เหรียญที่ใหญ่ที่สุดอีกต่อไป ผู้เล่นในระบบนิเวศ BTC โปรโตคอลสินทรัพย์ Client-Side Validation (CSV) เริ่มได้รับความสนใจ แตกต่างจากโปรโตคอลสินทรัพย์ BTC แบบดั้งเดิมโดยผสมผสานคุณสมบัติต่างๆ สำหรับความสามารถในการปรับขนาดของ Bitcoin แต่เมื่อต้องเผชิญกับโปรโตคอลสินทรัพย์จำนวนมากในระบบนิเวศ BTC เราจึงต้องถามว่า: อะไรคือความแตกต่าง? และเราควรเลือกและค้นหาโอกาสของเราเองจากโปรโตคอลสินทรัพย์จำนวนมากเหล่านี้อย่างไร

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

เหรียญสี

แนวคิดของ Colored Coins ได้รับการเสนอครั้งแรกโดย Yoni Assia ซึ่งเป็น CEO คนปัจจุบันของ eToro ในบทความที่เขียนเมื่อวันที่ 27 มีนาคม 2012 ในหัวข้อ “bitcoin 2.X (aka Coloured bitcoin)” บทความตั้งข้อสังเกตว่า Bitcoin ซึ่งเป็นเทคโนโลยีพื้นฐานนั้นสมบูรณ์แบบ เหมือนกับที่ HTTP เป็นรากฐานของอินเทอร์เน็ต ดังนั้นบนพื้นฐานของการนำ BTC มาใช้ซ้ำ โปรโตคอลโทเค็น Colored Coins จึงได้รับการออกแบบ

Yoni Assia มีเป้าหมายที่จะสร้างเศรษฐกิจ BTC 2.0 ด้วยวิธีนี้ - ชุมชนใดๆ ก็สามารถสร้างสกุลเงินที่หลากหลายด้วยวิธีนี้ได้ วิธีการใช้ Bitcoin เป็นเทคโนโลยีพื้นฐานในการเคลียร์ธุรกรรมและหลีกเลี่ยงการใช้จ่ายซ้ำซ้อนถือเป็นแนวคิดที่โดดเด่นมากอย่างไม่ต้องสงสัยในขณะนั้น

ตามแนวทางปฏิบัติสำหรับการออกสินทรัพย์โดยใช้ Bitcoin วิธีการของ Colored Coins คือการ "ระบายสี" จำนวน Bitcoin เพื่อเป็นตัวแทนของสินทรัพย์เหล่านี้ Bitcoins ที่ทำเครื่องหมายไว้เหล่านี้ยังคงใช้งานได้จริง Bitcoins แต่ยังเป็นตัวแทนของสินทรัพย์หรือมูลค่าอื่นอีกด้วย แต่แนวคิดนี้สามารถนำไปใช้กับ Bitcoin ได้อย่างไร?

เมื่อวันที่ 3 กรกฎาคม 2014 ChromaWay ได้พัฒนาโปรโตคอล Colored Coins (EPOBC) แบบ Pay-to-Script-Hash (P2SH) ที่ปรับปรุงใหม่ ซึ่งช่วยให้กระบวนการสร้างเหรียญสีง่ายขึ้นสำหรับนักพัฒนา นี่เป็นโปรโตคอลแรกสุดที่ใช้ฟังก์ชัน OP_RETURN ของ Bitcoin Script

การใช้งานขั้นสุดท้ายจะแสดงในภาพต่อไปนี้:

)

การใช้งานนี้มีความกระชับมาก แต่ก็นำมาซึ่งปัญหามากมายเช่นกัน:

โทเค็นที่เป็นเนื้อเดียวกันและมูลค่าการผูกขั้นต่ำ

ในการทำธุรกรรมกำเนิด ถ้าเหรียญสีผูกกับ 1,000 sats หน่วยแยกที่เล็กที่สุดของเหรียญสีนี้คือ 1 sat ซึ่งหมายความว่าเนื้อหาหรือโทเค็นสามารถแบ่งหรือจัดสรรได้สูงสุด 1,000 ส่วน (แต่นี่เป็นเพียงทางทฤษฎีเท่านั้น เพื่อป้องกันการโจมตีของฝุ่น เช่น sat เคยตั้งไว้ที่ 546 SAT และต่อมาเป็นลำดับที่สูงกว่า ).

ปัญหาการตรวจสอบ

เพื่อยืนยันความถูกต้องและความเป็นเจ้าของเหรียญสี จำเป็นต้องติดตามและตรวจสอบตั้งแต่ธุรกรรมต้นกำเนิดของสินทรัพย์จนถึง UTXO ปัจจุบัน ดังนั้นจึงจำเป็นอย่างยิ่งที่จะต้องพัฒนากระเป๋าเงินเฉพาะและโหนดแบบเต็มและแม้แต่เบราว์เซอร์

ความเสี่ยงที่อาจเกิดขึ้นจากการเซ็นเซอร์คนขุดแร่

เนื่องจากลักษณะเฉพาะของ ColoredTransaction ซึ่งเกี่ยวข้องกับการเขียนข้อมูลเมตาดาต้าลงในเอาต์พุต จึงมีความเป็นไปได้ที่จะเซ็นเซอร์ผู้ขุดแร่

เหรียญสีเป็นระบบติดตามสินทรัพย์โดยพื้นฐานแล้วใช้กฎการตรวจสอบของ Bitcoin เพื่อติดตามการโอนสินทรัพย์ อย่างไรก็ตาม เพื่อพิสูจน์ว่าเอาต์พุตเฉพาะใดๆ (txout) แสดงถึงสินทรัพย์บางอย่าง จำเป็นต้องมีห่วงโซ่การโอนทั้งหมดตั้งแต่ต้นทางของสินทรัพย์จนถึงปัจจุบัน ซึ่งหมายความว่าการตรวจสอบความถูกต้องของธุรกรรมอาจต้องใช้การพิสูจน์ที่ยาวนาน เพื่อแก้ไขปัญหานี้ มีข้อเสนอสำหรับ OP_CHECKCOLORVERIFY เพื่อช่วยในการตรวจสอบความถูกต้องของธุรกรรม Colored Coins บน BTC โดยตรง แต่ข้อเสนอนี้ไม่ผ่าน

ICO แรกในอุตสาหกรรม Cryptocurrency: Mastercoin

แนวคิดเริ่มต้นของ Mastercoin ถูกเสนอโดย JR Willett ในปี 2012 เขาได้ตีพิมพ์เอกสารไวท์เปเปอร์ชื่อ “The Second Bitcoin Whitepaper” ซึ่งอธิบายแนวคิดของการสร้างสินทรัพย์หรือโทเค็นใหม่บนบล็อคเชนที่มีอยู่ของ Bitcoin ซึ่งต่อมารู้จักกันในชื่อ “MasterCoin” ต่อมาได้เปลี่ยนชื่อเป็น Omni Layer

โครงการ Mastercoin ดำเนินการขายโทเค็นครั้งแรก (สิ่งที่เราเรียกว่า ICO หรือการเสนอขายเหรียญเริ่มต้น) ในปี 2013 และประสบความสำเร็จในการระดมทุนหลายล้านดอลลาร์ นี่ถือเป็น ICO ครั้งแรกในประวัติศาสตร์ แอปพลิเคชั่นที่โดดเด่นที่สุดของ Mastercoin คือ Tether (USDT) ซึ่งเป็นเหรียญ stablecoin ที่มีชื่อเสียงที่สุด ซึ่งเปิดตัวครั้งแรกบน Omni Layer

ในความเป็นจริง แนวคิดของ Mastercoin มีมาก่อนเหรียญสี เหตุผลที่มีการพูดคุยกันในประเด็นที่สองก็คือ เมื่อเปรียบเทียบกับเหรียญสีแล้ว Mastercoin ถือเป็นโซลูชั่นที่ค่อนข้างซับซ้อนกว่า Mastercoin สร้างเลเยอร์โหนดที่สมบูรณ์ จึงมีฟังก์ชันที่ซับซ้อนมากขึ้น (เช่น สัญญาอัจฉริยะ) ในขณะที่ Colored Coins นั้นเรียบง่ายกว่าและตรงกว่า โดยเน้นไปที่ "การระบายสี" หรือการทำเครื่องหมาย Bitcoin UTXO เป็นหลักเพื่อเป็นตัวแทนของสินทรัพย์อื่น ๆ

ความแตกต่างที่สำคัญจาก Colored Coins คือ Mastercoin เผยแพร่พฤติกรรมการทำธุรกรรมประเภทต่างๆ บนห่วงโซ่เท่านั้น โดยไม่บันทึกข้อมูลสินทรัพย์ที่เกี่ยวข้อง ในโหนด Mastercoin ฐานข้อมูลแบบจำลองสถานะจะได้รับการดูแลโดยการสแกนบล็อก Bitcoin ในโหนดนอกเครือข่าย

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

อย่างไรก็ตาม ในการใช้ตรรกะที่ซับซ้อนของ Mastercoin ผู้ใช้จำเป็นต้องเชื่อถือสถานะในฐานข้อมูลนอกเครือข่ายของโหนดหรือเรียกใช้โหนด Omni Layer ของตนเองเพื่อตรวจสอบ

สรุป:

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

ตามข้อมูลที่ OmniBolt ให้ไว้: Omni Layer กำลังเสนอโปรโตคอลสินทรัพย์ UBA (UTXO Based Asset) ใหม่ให้กับ Tether ซึ่งจะใช้การอัพเกรด Taproot เพื่อเข้ารหัสข้อมูลสินทรัพย์ลงใน tapleaf เปิดใช้งานฟังก์ชันต่างๆ เช่น การชำระเงินแบบมีเงื่อนไข ในขณะเดียวกัน OmniBolt กำลังแนะนำ Stark ให้กับโครงสร้างพื้นฐาน Lightning Network ของ OmniLayer

แนวคิดของการตรวจสอบฝั่งไคลเอ็นต์

เพื่อให้เข้าใจแนวคิดของการตรวจสอบฝั่งไคลเอ็นต์ เราต้องย้อนกลับไปในปีถัดจากการเกิดขึ้นของ Colored Coins และ Mastercoin ซึ่งก็คือปี 2013 ในปีนั้น Peter Todd ได้ตีพิมพ์บทความเรื่อง “Disentangling Crypto-Coin Mining: Timestamping, Proof-of-Publication, and Validation” แม้ว่าชื่อของบทความดูเหมือนจะไม่เกี่ยวข้องโดยตรงกับการตรวจสอบฝั่งไคลเอ็นต์ แต่การอ่านอย่างละเอียดพบว่าบทความนี้มีแนวคิดแรกสุดเกี่ยวกับการตรวจสอบความถูกต้องฝั่งไคลเอ็นต์

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

ตามความคิดของ Peter Todd ก่อนอื่นมาทำความเข้าใจปัญหาที่ BTC (Bitcoin) แก้ไขได้จริง ในมุมมองของ Peter Todd BTC สามารถแก้ไขปัญหาได้สามประการ:

หลักฐานการตีพิมพ์

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

ฉันทามติสั่งซื้อ

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

การตรวจสอบความถูกต้อง (ไม่บังคับ)

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

ณ จุดนี้ คุณอาจนึกถึง Ominilayer ที่กล่าวถึงข้างต้น Ominilayer เองไม่ได้มอบหมายการคำนวณและการตรวจสอบสถานะให้กับ BTC แต่ยังคงนำความปลอดภัยของ BTC มาใช้ซ้ำ ในทางกลับกัน Colored Coins มอบหมายการติดตามสถานะให้กับ BTC การมีอยู่ของทั้งสองแสดงให้เห็นว่าการตรวจสอบความถูกต้องไม่จำเป็นต้องเกิดขึ้นบนเครือข่าย

ดังนั้นการตรวจสอบฝั่งไคลเอ็นต์จะตรวจสอบธุรกรรมได้อย่างมีประสิทธิภาพอย่างไร

อันดับแรกเรามาดูกันว่าต้องมีการตรวจสอบอะไรบ้าง:

  • สถานะ (การตรวจสอบตรรกะของธุรกรรม)

  • ความถูกต้องของอินพุต TxIn (เพื่อป้องกันการใช้จ่ายซ้ำซ้อน)

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

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

Peter Todd เสนอโครงสร้างของแผนผังความมุ่งมั่นดังต่อไปนี้:

CTxIn -> CTxOut -> <เส้นทาง Merkle> <merkle path> -> CTransaction -> <เส้นทาง Merkle> <merkle path> -> CTxIn

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

ซีลแบบใช้ครั้งเดียว

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

สำหรับ SealProtocol มีสามองค์ประกอบและสองการดำเนินการ

องค์ประกอบพื้นฐาน:

  1. l: ประทับตรานั่นคือประทับตรา
  2. ม: ข้อความ ข้อความ
  3. ใน:พยาน, พยาน

การดำเนินงานขั้นพื้นฐาน: มีการดำเนินการพื้นฐานสองประการ:

  1. ปิด(l,m) → w: ในข้อความปิด messagemupper ให้สร้างพยานใน
  2. Verify(l,w,m) → bool: ยืนยัน sealall คุณอยู่ในข่าวหรือเปล่า?ปิดผิด

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

ประการแรก Single-Use Seal เป็นแนวคิดที่ทำให้แน่ใจว่าสินทรัพย์หรือข้อมูลบางอย่างจะถูกใช้หรือล็อคเพียงครั้งเดียวเท่านั้น ในบริบทของ Bitcoin โดยทั่วไปหมายความว่า UTXO (เอาต์พุตธุรกรรมที่ยังไม่ได้ใช้) สามารถใช้ได้เพียงครั้งเดียวเท่านั้น ดังนั้น เอาท์พุตของธุรกรรม Bitcoin จึงถือเป็นการปิดผนึกแบบครั้งเดียว และเมื่อเอาท์พุตนี้ถูกใช้เป็นอินพุตสำหรับธุรกรรมอื่น ซีลจะ "เสียหาย" หรือ "ถูกใช้งาน"

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

มันง่ายกว่านี้ได้ไหม?

ตราประทับแบบใช้ครั้งเดียว นั่นคือ blockchain ใด ๆ ถือเป็นฐานข้อมูล เราจัดเก็บคำสัญญาของข้อความบางอย่างไว้ในฐานข้อมูลนี้ในทางใดทางหนึ่ง และรักษาสถานะที่ใช้หรือที่จะถูกใช้งาน

ใช่ มันง่ายมาก

โดยสรุป สินทรัพย์ที่ลูกค้าตรวจสอบแล้วมีลักษณะดังต่อไปนี้:

  1. การจัดเก็บข้อมูลแบบออฟไลน์: ประวัติการทำธุรกรรม ความเป็นเจ้าของ และข้อมูลอื่น ๆ ที่เกี่ยวข้องส่วนใหญ่ของสินทรัพย์ที่ลูกค้าตรวจสอบจะถูกจัดเก็บแบบออฟไลน์ สิ่งนี้ช่วยลดความต้องการจัดเก็บข้อมูลออนไลน์ได้อย่างมากและช่วยปรับปรุงความเป็นส่วนตัว
  2. กลไกข้อผูกมัด: แม้ว่าข้อมูลสินทรัพย์จะถูกจัดเก็บแบบออฟไลน์ แต่การเปลี่ยนแปลงหรือถ่ายโอนข้อมูลนี้จะถูกบันทึกแบบออนไลน์ผ่านข้อผูกพัน ข้อผูกพันเหล่านี้ช่วยให้การทำธุรกรรมออนไลน์สามารถอ้างอิงสถานะนอกเครือข่ายได้ ดังนั้นจึงรับประกันความสมบูรณ์และการไม่เปลี่ยนแปลงข้อมูลนอกเครือข่าย
  3. พยานออนไลน์ (ไม่จำเป็นต้องเป็น BTC): แม้ว่าข้อมูลและการตรวจสอบส่วนใหญ่จะเป็นแบบออฟไลน์ แต่สินทรัพย์ที่ได้รับการยืนยันจากลูกค้ายังคงสามารถใช้ประโยชน์จากการรักษาความปลอดภัยของห่วงโซ่พื้นฐาน (การออกหลักฐาน การสั่งซื้อธุรกรรม) ผ่านข้อผูกพันที่ฝังอยู่ใน -โซ่.
  4. การยืนยันเสร็จสิ้นในฝั่งไคลเอ็นต์: งานการยืนยันส่วนใหญ่เสร็จสิ้นบนอุปกรณ์ของผู้ใช้ ซึ่งหมายความว่าโหนดเครือข่ายทั้งหมดไม่จำเป็นต้องมีส่วนร่วมในการตรวจสอบธุรกรรมแต่ละรายการ มีเพียงผู้เข้าร่วมที่เกี่ยวข้องเท่านั้นที่ต้องตรวจสอบความถูกต้องของธุรกรรม

สำหรับผู้ที่ใช้การตรวจสอบสินทรัพย์ฝั่งไคลเอ็นต์ มีอีกประเด็นที่ควรทราบ:

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

ผู้บุกเบิกในการตรวจสอบฝั่งไคลเอ็นต์ (CSV): RGB

แนวคิดของ RGB ได้รับการเสนอโดย Giacomo Zucco ซึ่งเป็นบุคคลที่มีชื่อเสียงในชุมชนหลังปี 2015 เนื่องจากการเพิ่มขึ้นของ Ethereum และการแพร่กระจายของ ICO และก่อน ICO ผู้คนจำนวนมากพยายามทำสิ่งต่าง ๆ นอกเหนือจาก Bitcoin เช่นโปรเจ็กต์ Mastercoin และ Colored Coins .

Giacomo Zucco แสดงความผิดหวัง เขาเชื่อว่าโครงการเหล่านี้ด้อยกว่า Bitcoin และเขาเชื่อว่าวิธีการนำโทเค็นไปใช้กับ Bitcoin ก่อนหน้านี้นั้นไม่เหมาะสม ในกระบวนการนี้ เขาได้พบกับ Peter Todd และรู้สึกทึ่งกับแนวคิดของ Peter Todd ในเรื่อง Client-Side-Validation จากนั้นเขาก็เริ่มเสนอแนวคิดRGB

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

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

กลไกความมุ่งมั่นของ RGB: Pedersen Hash

ในแง่ของกลไกความมุ่งมั่น RGB ใช้ Pedersen Hash ข้อได้เปรียบอยู่ที่ความสามารถในการยอมรับคุณค่าโดยไม่ต้องเปิดเผย การใช้ Pedersen Hash เพื่อสร้างแผนผัง Merkle หมายความว่าคุณสามารถสร้างแผนผัง Merkle ที่ได้รับการคุ้มครองความเป็นส่วนตัว ซึ่งจะซ่อนค่าต่างๆ ไว้ภายในต้นไม้นั้น โครงสร้างนี้สามารถใช้ในโปรโตคอลการป้องกันความเป็นส่วนตัวเฉพาะบางอย่าง เช่น โครงการสกุลเงินดิจิทัลที่ไม่ระบุตัวตนบางโครงการ อย่างไรก็ตาม อาจไม่เหมาะกับสินทรัพย์ CSV ซึ่งจะกล่าวถึงในภายหลังเมื่อเปรียบเทียบกับสินทรัพย์ Taproot

การออกแบบเครื่องเสมือนของ RGB: จากความเรียบง่ายไปจนถึง AluVM

RGB มีเป้าหมายไม่เพียงแต่จะใช้โปรโตคอลสินทรัพย์ที่ผ่านการตรวจสอบโดยไคลเอ็นต์เท่านั้น แต่ยังขยายไปสู่การดำเนินการเครื่องเสมือนและการเขียนโปรแกรมสัญญาของ Turing ที่สมบูรณ์อีกด้วย ในการออกแบบ RGB ในยุคแรกๆ อ้างว่าใช้ภาษาโปรแกรมที่เรียกว่า Simplicity ภาษานี้มีเอกลักษณ์เฉพาะด้วยการสร้างหลักฐานการดำเนินการในขณะที่ดำเนินการนิพจน์ ทำให้ง่ายต่อการตรวจสอบสัญญาที่เขียนไว้อย่างเป็นทางการ (เพื่อหลีกเลี่ยงข้อบกพร่อง) อย่างไรก็ตามการพัฒนาภาษานี้ไม่เหมาะและประสบปัญหาในที่สุด สิ่งนี้นำไปสู่การเกิดโปรโตคอล RGB ที่ยากลำบากในปีนั้นโดยตรง ท้ายที่สุดแล้ว RGB เริ่มใช้ AluVM ซึ่งพัฒนาโดย Maxim โดยมีเป้าหมายเพื่อหลีกเลี่ยงพฤติกรรมที่ไม่ได้กำหนดไว้ ซึ่งคล้ายกับความเรียบง่ายเริ่มแรก กล่าวกันว่า AluVM ใหม่จะถูกแทนที่ด้วยภาษาการเขียนโปรแกรมที่เรียกว่า Contractum ซึ่งปัจจุบันใช้ Rust ในอนาคต

ทิศทางการขยายเลเยอร์ 2 ของ RGB: Lightning Network หรือ Sidechain?

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

RGB และเครือข่ายสายฟ้า

พูดง่ายๆ ก็คือ หลักการของ Lightning Network คือทั้งสองฝ่ายที่เกี่ยวข้องในการทำธุรกรรมลงนามในสัญญา (ธุรกรรมที่มีข้อผูกพัน) นอกเครือข่าย สิ่งเหล่านี้ช่วยให้แน่ใจว่าหากฝ่ายใดฝ่ายหนึ่งฝ่าฝืนสัญญา ฝ่ายที่ได้รับความเดือดร้อนสามารถส่งสัญญา (ธุรกรรมข้อผูกพัน) ให้กับ BTC เพื่อการชำระหนี้ รับเงินของพวกเขา และลงโทษอีกฝ่าย กล่าวอีกนัยหนึ่ง Lightning Network รับประกันความปลอดภัยของธุรกรรมนอกเครือข่ายผ่านการออกแบบโปรโตคอลและทฤษฎีเกม

RGB สามารถสร้างโครงสร้างพื้นฐาน Lightning Network ของตัวเองได้โดยการออกแบบกฎสัญญาช่องทางการชำระเงินที่เหมาะกับตัวเอง แต่ความซับซ้อนของ Lightning Network นั้นสูงมาก และการสร้างระบบนี้ไม่ใช่เรื่องง่าย อย่างไรก็ตาม ในทางกลับกัน Lightnling Labs ได้ปลูกฝังสาขานี้มาหลายปีแล้ว และ LND มีส่วนแบ่งตลาดมากกว่า 90%

Sidechain ของ RGB: Prime

LNP-BP ซึ่งปัจจุบันรักษาโปรโตคอล RGB โดย Maxim จะออกข้อเสนอชื่อ Prime ในเดือนมิถุนายน 2023 ซึ่งเป็นแผนการขยายสินทรัพย์ที่ลูกค้าตรวจสอบแล้ว ในนั้นเขาได้วิพากษ์วิจารณ์ sidechain ที่มีอยู่และแผนการขยาย Lightning Network ว่าซับซ้อนเกินไปในการพัฒนา Maxim ระบุว่าเขาเชื่อว่านอกเหนือจาก Prime แล้ว วิธีการขยายอื่นๆ ยังรวมถึง NUCLEUS multi-node Lightning channel และโรงงาน Ark/Enigma channel ซึ่งทั้งสองวิธีนี้ต้องใช้เวลาในการพัฒนามากกว่าสองปี อย่างไรก็ตาม Prime สามารถแล้วเสร็จได้ภายในเวลาเพียงหนึ่งปี

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

  1. บริการประทับเวลา: การกำหนดลำดับธุรกรรมภายในเวลาเพียง 10 วินาที

  2. หลักฐาน: จัดเก็บในรูปแบบ PMT ผลิตและเผยแพร่พร้อมกับส่วนหัวของบล็อก

  3. การประทับตราแบบครั้งเดียว: โปรโตคอลการประทับตราแบบนามธรรมแบบครั้งเดียว ซึ่งรับประกันการป้องกันการใช้จ่ายซ้ำซ้อน หากใช้งานบน Bitcoin ก็สามารถเชื่อมโยงกับ UTXO ได้ ซึ่งคล้ายกับการออกแบบ RGB ในปัจจุบัน

  4. โปรโตคอลสัญญาอัจฉริยะ: สัญญาที่แบ่งส่วนได้ - RGB (เปลี่ยนได้)

เพื่อแก้ไขปัญหาเวลายืนยันธุรกรรม RGB Prime ใช้บริการประทับเวลาเพื่อยืนยันธุรกรรมนอกเครือข่ายอย่างรวดเร็วและสรุปธุรกรรมและ ID ลงในบล็อก ในขณะเดียวกัน หลักฐานการทำธุรกรรมบน Prime สามารถรวมเพิ่มเติมผ่าน PMT จากนั้นจึงยึดกับ BTC ในลักษณะที่คล้ายกับจุดตรวจ

โปรโตคอลสินทรัพย์ CSV ที่ใช้ Taproot: สินทรัพย์ Taproot

Taproot Assets เป็นโปรโตคอลสินทรัพย์ CSV ที่ใช้ Taproot ซึ่งใช้ในการออกสินทรัพย์ที่ลูกค้าตรวจสอบแล้วบนบล็อกเชน Bitcoin สินทรัพย์เหล่านี้สามารถซื้อขายได้ทันทีในปริมาณมากด้วยต้นทุนที่ต่ำผ่าน Lightning Network หัวใจสำคัญของ Taproot Assets อยู่ที่การใช้ประโยชน์จากความปลอดภัยและความเสถียรของเครือข่าย Bitcoin ตลอดจนความเร็ว ความสามารถในการขยายขนาด และต้นทุนต่ำของ Lightning Network โปรโตคอลนี้ได้รับการออกแบบและพัฒนาโดย CTO ของ Lightnling Labs ซึ่งอาจเป็นบุคคลเพียงคนเดียวบนโลกใบนี้ที่เป็นผู้นำการพัฒนาทั้งไคลเอนต์ Bitcoin (BTCD) และไคลเอนต์ Lightning Network (LND) เป็นการส่วนตัว และมีความเข้าใจอย่างลึกซึ้ง ของ BTC

ธุรกรรมของ Taproot มีเพียงแฮชรูทของสคริปต์เนื้อหาเท่านั้น ทำให้ยากสำหรับผู้สังเกตการณ์ภายนอกในการระบุว่าเกี่ยวข้องกับทรัพย์สินของ Taproot หรือไม่ เนื่องจากแฮชนั้นเป็นข้อมูลทั่วไปและสามารถแสดงข้อมูลใดๆ ได้ ด้วยการอัพเกรด Taproot Bitcoin ได้รับความสามารถของสัญญาอัจฉริยะ (TapScript) ด้วยเหตุนี้ การเข้ารหัสสินทรัพย์ของ Taproot Assets จึงคล้ายกับการสร้างคำจำกัดความโทเค็นที่คล้ายกับ ERC20 หรือ ERC721 ดังนั้น Bitcoin ไม่เพียงแต่มีหน้าที่ในการกำหนดสินทรัพย์เท่านั้น แต่ยังมีความสามารถในการเขียนสัญญาอัจฉริยะ ซึ่งเป็นการวางรากฐานสำหรับโครงสร้างพื้นฐานสัญญาอัจฉริยะของโทเค็นบน Bitcoin

โครงสร้างการเข้ารหัสของ Taproot Assets มีดังนี้: [คำอธิบายสิ้นสุดที่นี่ ซึ่งระบุส่วนถัดไปของบทความที่น่าจะเจาะลึกรายละเอียดทางเทคนิคของโครงสร้างการเข้ารหัสของ Taproot Assets]

รูปภาพโดย Lightning Labs CTO เนื้อย่าง

เนื่องจากเป็นโปรโตคอลสินทรัพย์ CSV (CoinSwap) สินทรัพย์ Taproot ได้รับการออกแบบให้มีความคล่องตัวมากกว่าเมื่อเทียบกับ RGB พวกเขาใช้ความก้าวหน้าในปัจจุบันให้เกิดประโยชน์สูงสุดในระบบนิเวศ BTC เช่นการอัพเกรด Taproot และ PSBT (ธุรกรรม Bitcoin ที่ลงนามบางส่วน) ความแตกต่างที่สำคัญที่สุดระหว่าง Taproot Assets และ RGB ในแง่ของความสามารถในการขยายแอปพลิเคชันอยู่ที่การดำเนินการ VM (Virtual Machine) Taproot Assets ใช้ TaprootScriptVM ซึ่งเหมือนกับ VM ดั้งเดิมที่ใช้โดย BTC ในช่วงไม่กี่ปีที่ผ่านมา การศึกษาโครงสร้างพื้นฐานจำนวนมากสำหรับ BTC ได้อิงจาก TapScript อย่างไรก็ตาม เนื่องจากการอัพเกรด BTC เป็นไปอย่างช้าๆ การศึกษาเหล่านี้จึงไม่ได้ดำเนินการอย่างรวดเร็ว ทำให้ Taproot Assets กลายเป็นพื้นที่ทดสอบที่มีศักยภาพสำหรับแนวคิดใหม่เหล่านี้

Taproot Assets และ RGB แตกต่างกันอย่างไร

  1. การตรวจสอบธุรกรรมและความเป็นมิตรของ Light Node

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

  1. การดำเนินการ VM

Taproot Assets เกิดขึ้นหลังจากการอัพเกรด Taproot พวกเขาใช้ TaprootScriptVM ซึ่งเป็นเอ็นจิ้นการเรียกใช้สคริปต์ที่มีอยู่ในการอัพเกรด Bitcoin หลัง Taproot และ vPSBT ซึ่งเป็นรูปแบบหนึ่งของ PSBT ของ BTC เมื่อกลไกช่องสัญญาณฟ้าผ่าของ Taproot Assets เสร็จสมบูรณ์ จะสามารถนำโครงสร้างพื้นฐาน LND ในปัจจุบันทั้งหมดและผลิตภัณฑ์ Lightning Labs ที่ผ่านมากลับมาใช้ใหม่ได้ทันที (ปัจจุบัน LND ครองเครือข่าย Lightning มากกว่า 90%) ข้อเสนอ BitVM ล่าสุด ซึ่งใช้ TaprootScript เช่นกัน ก็สนับสนุน Taproot Assets ในทางทฤษฎี อย่างไรก็ตาม VM ของ RGB และกฎการตรวจสอบ (SCHEMA) นั้นมีอยู่ในตัวเอง ก่อให้เกิดระบบนิเวศที่ค่อนข้างปิด การพัฒนาของ RGB นั้นส่วนใหญ่ถูกจำกัดอยู่ในระบบนิเวศของมัน และการบูรณาการเข้ากับระบบนิเวศของ Bitcoin นั้นไม่ได้ใกล้เคียงอย่างที่คิด ตัวอย่างเช่น ความสัมพันธ์เพียงอย่างเดียวของ RGB กับการอัปเกรด Taproot คือการเข้ารหัสข้อมูลความมุ่งมั่นของลูกโซ่ลงใน TapLeaf ของ Witness

  1. สัญญาอัจฉริยะ

ในการใช้งานปัจจุบันของ RGB สัญญาและ VM ได้รับการเน้นย้ำอย่างมาก อย่างไรก็ตาม สัญญาอัจฉริยะยังไม่ปรากฏใน Taproot Assets ในปัจจุบัน RGB ไม่ได้อธิบายว่าการปรับเปลี่ยน Global State ซิงโครไนซ์กับส่วนสัญญาแต่ละรายการ (UTXO) อย่างไร และวิธีที่ Pedersen Commitment ซึ่งรับรองเฉพาะปริมาณสินทรัพย์ทั้งหมดเท่านั้น จะตรวจจับการปลอมแปลงกับรัฐอื่นๆ ได้อย่างไร ในทางตรงกันข้าม Taproot Assets ซึ่งมีการออกแบบที่เรียบง่ายกว่า ปัจจุบันจัดเก็บเฉพาะยอดคงเหลือของสินทรัพย์เท่านั้น และไม่มีพื้นที่จัดเก็บที่กว้างขวาง ส่งผลให้การอภิปรายเกี่ยวกับสัญญาอัจฉริยะเกิดก่อนเวลาอันควร อย่างไรก็ตาม Lightning Labs ระบุว่า Taproot Assets จะมุ่งเน้นไปที่การออกแบบสัญญาอัจฉริยะในปีหน้า

  1. ศูนย์กลางการซิงโครไนซ์

ตามที่เข้าใจจากหลักการพื้นฐานของการตรวจสอบสินทรัพย์ฝั่งไคลเอ็นต์ การถือหลักฐานมีความสำคัญพอๆ กับการถือกุญแจส่วนตัว แต่จะเกิดอะไรขึ้นถ้า Proof หายไปในฝั่งไคลเอ็นต์ของผู้ใช้? ใน Taproot Assets ปัญหานี้สามารถแก้ไขได้ผ่าน 'จักรวาล' จักรวาลเป็นต้นไม้ Merkle กระจัดกระจายที่สาธารณชนตรวจสอบได้ ซึ่งครอบคลุมทรัพย์สินตั้งแต่หนึ่งรายการขึ้นไป จักรวาลไม่ได้โฮสต์ทรัพย์สินของ Taproot ซึ่งแตกต่างจากแผนผังทรัพย์สินของ Taproot ทั่วไป แต่จะผูกพันกับชุดย่อยของประวัติสินทรัพย์ตั้งแต่หนึ่งรายการขึ้นไป ใน RGB บทบาทนี้เล่นโดย Storm ซึ่งจะซิงโครไนซ์ข้อมูลการพิสูจน์นอกเชนผ่าน P2P อย่างไรก็ตาม เนื่องจากเหตุผลทางประวัติศาสตร์ของทีมพัฒนา RGB รูปแบบการพิสูจน์เหล่านี้จึงเข้ากันไม่ได้ในปัจจุบัน มีรายงานว่าทีมระบบนิเวศของ RGB DIBA กำลังพัฒนา 'คาร์บอนาโด' เพื่อแก้ไขปัญหานี้ แม้ว่าความคืบหน้าจะไม่ชัดเจนก็ตาม

  1. การดำเนินการทางวิศวกรรม

ไลบรารีทั้งหมดที่ใช้โดย Taproot Assets ผ่านการทดสอบตามเวลา เนื่องจาก Lightning Labs มีไคลเอนต์ Bitcoin (BTCD), ไคลเอนต์เครือข่าย Lightning (LND) และการใช้งาน Wallet lib มากมาย ในทางตรงกันข้าม ไลบรารีส่วนใหญ่ที่ใช้ใน RGB นั้นถูกกำหนดด้วยตนเอง และจากมุมมองมาตรฐานอุตสาหกรรม การใช้งาน RGB ยังอยู่ในขั้นทดลอง”

การอภิปรายสั้น ๆ เกี่ยวกับอนาคตของการขยาย BTC

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

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

การคำนวณแบบ on-chain น้อยลง, การตรวจสอบความถูกต้องแบบ on-chain มากขึ้น

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

การตรวจสอบความถูกต้องเกิดขึ้นที่ไหน? นี้เป็นสิ่งสำคัญ

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

จากมุมมองของการดำเนินการตรวจสอบ เรามีแนวทางในการขยาย 3 ประการ:

  1. 1. การตรวจสอบแบบออนไลน์ (OP-ZKP)
  2. หาก OP-ZKP ถูกนำไปใช้โดยตรงใน TaprootScriptVM นั่นหมายถึงการบูรณาการความสามารถในการตรวจสอบ ZKP เข้ากับ BTC เอง ควบคู่ไปกับการออกแบบ Covenant บางประการสำหรับโปรโตคอลการชำระเงิน สร้างแผนการขยาย Zk-Rollup ที่สืบทอดความปลอดภัยของ BTC อย่างไรก็ตาม กระบวนการอัปเกรดที่ช้าของ BTC ควบคู่ไปกับการใช้ op-code เฉพาะทางและอาจจำเป็นต้องอัปเกรดนั้น ต่างจากการใช้สัญญาการตรวจสอบความถูกต้องบน Ethereum ทำให้เกิดความท้าทาย
  3. 2. การตรวจสอบแบบกึ่งออนเชน (BitVM)
  4. การออกแบบ BitVM ไม่ได้มีไว้เพื่อรองรับตรรกะธุรกรรมปกติ Robin Linus ยังระบุด้วยว่าอนาคตของ BitVM อยู่ที่การสร้างตลาด cross-chain ฟรีสำหรับ SideChains ต่างๆ แนวทางของ BitVM ถือเป็นแบบกึ่งออนเชน เนื่องจากการคำนวณการตรวจสอบเหล่านี้ส่วนใหญ่ไม่ได้เกิดขึ้นแบบออนเชน แต่เป็นแบบออฟไลน์ อย่างไรก็ตาม เหตุผลสำคัญในการออกแบบ Taproot ของ BTC คือการใช้ TapScriptVM สำหรับการตรวจสอบความถูกต้องทางคอมพิวเตอร์เมื่อจำเป็น โดยในทางทฤษฎีจะสืบทอดความปลอดภัยของ BTC กระบวนการนี้ยังสร้างห่วงโซ่ความน่าเชื่อถือในการตรวจสอบความถูกต้องด้วย ตัวอย่างเช่น ก็เพียงพอแล้วหากหนึ่งในเครื่องมือตรวจสอบความถูกต้อง 'n' มีความซื่อสัตย์ คล้ายกับการสรุปเชิงบวก
  5. ต้นทุนออนไลน์ของ BitVM นั้นสูง แต่สามารถใช้หลักฐานการฉ้อโกง ZK เพื่อการปรับปรุงประสิทธิภาพได้หรือไม่ คำตอบคือไม่ เนื่องจากการนำหลักฐานการฉ้อโกงของ ZK ไปใช้นั้นขึ้นอยู่กับความสามารถในการตรวจสอบความถูกต้องของ ZKP แบบออนไลน์ ซึ่งนำเรากลับไปสู่ภาวะที่กลืนไม่เข้าคายไม่ออกของโครงการ OP-ZKP
  6. 3. การตรวจสอบความถูกต้องแบบ Off-chain (การตรวจสอบความถูกต้องฝั่งไคลเอ็นต์, เครือข่าย Lightning)
  7. เมื่อการตรวจสอบความถูกต้องเกิดขึ้นนอกเครือข่ายทั้งหมด เราจะกลับไปสู่โปรโตคอลสินทรัพย์ CSV และ Lightning Network ที่กล่าวถึงก่อนหน้านี้ ในการสนทนาก่อนหน้านี้ สังเกตว่าในการออกแบบ CSV เราไม่สามารถป้องกันการปลอมแปลงที่สมรู้ร่วมคิดได้อย่างสมบูรณ์ สิ่งที่เราทำได้คือใช้การเข้ารหัสและการออกแบบโปรโตคอลเพื่อรักษาความเสียหายจากการสมรู้ร่วมคิดที่เป็นอันตรายให้อยู่ภายในขอบเขตที่ควบคุมได้ ทำให้พฤติกรรมดังกล่าวไม่เกิดประโยชน์
  8. ข้อดีและข้อเสียของการตรวจสอบความถูกต้องแบบออฟไลน์มีความชัดเจน ข้อได้เปรียบคือการใช้ทรัพยากรออนไลน์น้อยที่สุด และมีศักยภาพในการขยายอย่างมาก ข้อเสียคือแทบเป็นไปไม่ได้เลยที่จะใช้ประโยชน์จากการรักษาความปลอดภัยของ BTC ได้อย่างเต็มที่ โดยจำกัดประเภทและวิธีการของธุรกรรมนอกเครือข่ายอย่างมาก นอกจากนี้ การตรวจสอบความถูกต้องแบบออฟไลน์ยังหมายความว่าข้อมูลจะถูกเก็บไว้แบบออฟไลน์ โดยมีการจัดการโดยผู้ใช้ ซึ่งต้องการข้อกำหนดที่สูงขึ้นสำหรับความปลอดภัยของสภาพแวดล้อมการทำงานของซอฟต์แวร์และความเสถียรของซอฟต์แวร์

แนวโน้มวิวัฒนาการการขยายตัว

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

ข้อสงวนสิทธิ์:

  1. บทความนี้พิมพ์ซ้ำจาก [กระจกเงา] ลิขสิทธิ์ทั้งหมดเป็นของผู้แต่งต้นฉบับ [Ben77] หากมีการคัดค้านการพิมพ์ซ้ำนี้ โปรดติดต่อทีมงาน Gate Learn แล้วพวกเขาจะจัดการโดยเร็วที่สุด
  2. การปฏิเสธความรับผิด: มุมมองและความคิดเห็นที่แสดงในบทความนี้เป็นเพียงของผู้เขียนเท่านั้น และไม่ถือเป็นคำแนะนำในการลงทุนใดๆ
  3. การแปลบทความเป็นภาษาอื่นดำเนินการโดยทีมงาน Gate Learn เว้นแต่จะกล่าวถึง ห้ามคัดลอก แจกจ่าย หรือลอกเลียนแบบบทความที่แปลแล้ว

การโอนแบบ Off-Chain: เส้นทางวิวัฒนาการของโปรโตคอลสินทรัพย์ Bitcoin

กลางJan 29, 2024
บทความนี้จะแนะนำทิศทางหลักสองประการของความสามารถในการปรับขนาดของ Bitcoin โดยการวิเคราะห์วิวัฒนาการของ Lightning Network และ RGB
การโอนแบบ Off-Chain: เส้นทางวิวัฒนาการของโปรโตคอลสินทรัพย์ Bitcoin

แนะนำสกุลเงิน

การออกสินทรัพย์ตาม BTC ถือเป็นประเด็นร้อนมาโดยตลอด จากการปรากฏตัวครั้งแรกของ Colored Coins ในปี 2011 ไปจนถึง Ordinal Protocol ที่ได้รับความนิยมเมื่อเร็ว ๆ นี้ ชุมชน BTC สามารถนำผู้เล่นใหม่ ๆ ออกมาและเป็นเอกฉันท์ได้เสมอ อย่างไรก็ตาม มีเพียงไม่กี่คนที่ผ่านการทดสอบของกาลเวลา ด้วย Lightling Labs ผู้ทะเยอทะยานที่ประกาศแผนการของพวกเขาในการสร้าง Stable Coin บน Taproot Assets และ Tether ได้ประกาศตัวเลือก RGB สำหรับการสร้างเหรียญ USDT บนเลเยอร์แรกของ Bitcoin เป็นที่ชัดเจนว่า OmniLayer (Mastercoin) ที่ครั้งหนึ่งเคยโด่งดังไม่ใช่เหรียญที่ใหญ่ที่สุดอีกต่อไป ผู้เล่นในระบบนิเวศ BTC โปรโตคอลสินทรัพย์ Client-Side Validation (CSV) เริ่มได้รับความสนใจ แตกต่างจากโปรโตคอลสินทรัพย์ BTC แบบดั้งเดิมโดยผสมผสานคุณสมบัติต่างๆ สำหรับความสามารถในการปรับขนาดของ Bitcoin แต่เมื่อต้องเผชิญกับโปรโตคอลสินทรัพย์จำนวนมากในระบบนิเวศ BTC เราจึงต้องถามว่า: อะไรคือความแตกต่าง? และเราควรเลือกและค้นหาโอกาสของเราเองจากโปรโตคอลสินทรัพย์จำนวนมากเหล่านี้อย่างไร

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

เหรียญสี

แนวคิดของ Colored Coins ได้รับการเสนอครั้งแรกโดย Yoni Assia ซึ่งเป็น CEO คนปัจจุบันของ eToro ในบทความที่เขียนเมื่อวันที่ 27 มีนาคม 2012 ในหัวข้อ “bitcoin 2.X (aka Coloured bitcoin)” บทความตั้งข้อสังเกตว่า Bitcoin ซึ่งเป็นเทคโนโลยีพื้นฐานนั้นสมบูรณ์แบบ เหมือนกับที่ HTTP เป็นรากฐานของอินเทอร์เน็ต ดังนั้นบนพื้นฐานของการนำ BTC มาใช้ซ้ำ โปรโตคอลโทเค็น Colored Coins จึงได้รับการออกแบบ

Yoni Assia มีเป้าหมายที่จะสร้างเศรษฐกิจ BTC 2.0 ด้วยวิธีนี้ - ชุมชนใดๆ ก็สามารถสร้างสกุลเงินที่หลากหลายด้วยวิธีนี้ได้ วิธีการใช้ Bitcoin เป็นเทคโนโลยีพื้นฐานในการเคลียร์ธุรกรรมและหลีกเลี่ยงการใช้จ่ายซ้ำซ้อนถือเป็นแนวคิดที่โดดเด่นมากอย่างไม่ต้องสงสัยในขณะนั้น

ตามแนวทางปฏิบัติสำหรับการออกสินทรัพย์โดยใช้ Bitcoin วิธีการของ Colored Coins คือการ "ระบายสี" จำนวน Bitcoin เพื่อเป็นตัวแทนของสินทรัพย์เหล่านี้ Bitcoins ที่ทำเครื่องหมายไว้เหล่านี้ยังคงใช้งานได้จริง Bitcoins แต่ยังเป็นตัวแทนของสินทรัพย์หรือมูลค่าอื่นอีกด้วย แต่แนวคิดนี้สามารถนำไปใช้กับ Bitcoin ได้อย่างไร?

เมื่อวันที่ 3 กรกฎาคม 2014 ChromaWay ได้พัฒนาโปรโตคอล Colored Coins (EPOBC) แบบ Pay-to-Script-Hash (P2SH) ที่ปรับปรุงใหม่ ซึ่งช่วยให้กระบวนการสร้างเหรียญสีง่ายขึ้นสำหรับนักพัฒนา นี่เป็นโปรโตคอลแรกสุดที่ใช้ฟังก์ชัน OP_RETURN ของ Bitcoin Script

การใช้งานขั้นสุดท้ายจะแสดงในภาพต่อไปนี้:

)

การใช้งานนี้มีความกระชับมาก แต่ก็นำมาซึ่งปัญหามากมายเช่นกัน:

โทเค็นที่เป็นเนื้อเดียวกันและมูลค่าการผูกขั้นต่ำ

ในการทำธุรกรรมกำเนิด ถ้าเหรียญสีผูกกับ 1,000 sats หน่วยแยกที่เล็กที่สุดของเหรียญสีนี้คือ 1 sat ซึ่งหมายความว่าเนื้อหาหรือโทเค็นสามารถแบ่งหรือจัดสรรได้สูงสุด 1,000 ส่วน (แต่นี่เป็นเพียงทางทฤษฎีเท่านั้น เพื่อป้องกันการโจมตีของฝุ่น เช่น sat เคยตั้งไว้ที่ 546 SAT และต่อมาเป็นลำดับที่สูงกว่า ).

ปัญหาการตรวจสอบ

เพื่อยืนยันความถูกต้องและความเป็นเจ้าของเหรียญสี จำเป็นต้องติดตามและตรวจสอบตั้งแต่ธุรกรรมต้นกำเนิดของสินทรัพย์จนถึง UTXO ปัจจุบัน ดังนั้นจึงจำเป็นอย่างยิ่งที่จะต้องพัฒนากระเป๋าเงินเฉพาะและโหนดแบบเต็มและแม้แต่เบราว์เซอร์

ความเสี่ยงที่อาจเกิดขึ้นจากการเซ็นเซอร์คนขุดแร่

เนื่องจากลักษณะเฉพาะของ ColoredTransaction ซึ่งเกี่ยวข้องกับการเขียนข้อมูลเมตาดาต้าลงในเอาต์พุต จึงมีความเป็นไปได้ที่จะเซ็นเซอร์ผู้ขุดแร่

เหรียญสีเป็นระบบติดตามสินทรัพย์โดยพื้นฐานแล้วใช้กฎการตรวจสอบของ Bitcoin เพื่อติดตามการโอนสินทรัพย์ อย่างไรก็ตาม เพื่อพิสูจน์ว่าเอาต์พุตเฉพาะใดๆ (txout) แสดงถึงสินทรัพย์บางอย่าง จำเป็นต้องมีห่วงโซ่การโอนทั้งหมดตั้งแต่ต้นทางของสินทรัพย์จนถึงปัจจุบัน ซึ่งหมายความว่าการตรวจสอบความถูกต้องของธุรกรรมอาจต้องใช้การพิสูจน์ที่ยาวนาน เพื่อแก้ไขปัญหานี้ มีข้อเสนอสำหรับ OP_CHECKCOLORVERIFY เพื่อช่วยในการตรวจสอบความถูกต้องของธุรกรรม Colored Coins บน BTC โดยตรง แต่ข้อเสนอนี้ไม่ผ่าน

ICO แรกในอุตสาหกรรม Cryptocurrency: Mastercoin

แนวคิดเริ่มต้นของ Mastercoin ถูกเสนอโดย JR Willett ในปี 2012 เขาได้ตีพิมพ์เอกสารไวท์เปเปอร์ชื่อ “The Second Bitcoin Whitepaper” ซึ่งอธิบายแนวคิดของการสร้างสินทรัพย์หรือโทเค็นใหม่บนบล็อคเชนที่มีอยู่ของ Bitcoin ซึ่งต่อมารู้จักกันในชื่อ “MasterCoin” ต่อมาได้เปลี่ยนชื่อเป็น Omni Layer

โครงการ Mastercoin ดำเนินการขายโทเค็นครั้งแรก (สิ่งที่เราเรียกว่า ICO หรือการเสนอขายเหรียญเริ่มต้น) ในปี 2013 และประสบความสำเร็จในการระดมทุนหลายล้านดอลลาร์ นี่ถือเป็น ICO ครั้งแรกในประวัติศาสตร์ แอปพลิเคชั่นที่โดดเด่นที่สุดของ Mastercoin คือ Tether (USDT) ซึ่งเป็นเหรียญ stablecoin ที่มีชื่อเสียงที่สุด ซึ่งเปิดตัวครั้งแรกบน Omni Layer

ในความเป็นจริง แนวคิดของ Mastercoin มีมาก่อนเหรียญสี เหตุผลที่มีการพูดคุยกันในประเด็นที่สองก็คือ เมื่อเปรียบเทียบกับเหรียญสีแล้ว Mastercoin ถือเป็นโซลูชั่นที่ค่อนข้างซับซ้อนกว่า Mastercoin สร้างเลเยอร์โหนดที่สมบูรณ์ จึงมีฟังก์ชันที่ซับซ้อนมากขึ้น (เช่น สัญญาอัจฉริยะ) ในขณะที่ Colored Coins นั้นเรียบง่ายกว่าและตรงกว่า โดยเน้นไปที่ "การระบายสี" หรือการทำเครื่องหมาย Bitcoin UTXO เป็นหลักเพื่อเป็นตัวแทนของสินทรัพย์อื่น ๆ

ความแตกต่างที่สำคัญจาก Colored Coins คือ Mastercoin เผยแพร่พฤติกรรมการทำธุรกรรมประเภทต่างๆ บนห่วงโซ่เท่านั้น โดยไม่บันทึกข้อมูลสินทรัพย์ที่เกี่ยวข้อง ในโหนด Mastercoin ฐานข้อมูลแบบจำลองสถานะจะได้รับการดูแลโดยการสแกนบล็อก Bitcoin ในโหนดนอกเครือข่าย

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

อย่างไรก็ตาม ในการใช้ตรรกะที่ซับซ้อนของ Mastercoin ผู้ใช้จำเป็นต้องเชื่อถือสถานะในฐานข้อมูลนอกเครือข่ายของโหนดหรือเรียกใช้โหนด Omni Layer ของตนเองเพื่อตรวจสอบ

สรุป:

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

ตามข้อมูลที่ OmniBolt ให้ไว้: Omni Layer กำลังเสนอโปรโตคอลสินทรัพย์ UBA (UTXO Based Asset) ใหม่ให้กับ Tether ซึ่งจะใช้การอัพเกรด Taproot เพื่อเข้ารหัสข้อมูลสินทรัพย์ลงใน tapleaf เปิดใช้งานฟังก์ชันต่างๆ เช่น การชำระเงินแบบมีเงื่อนไข ในขณะเดียวกัน OmniBolt กำลังแนะนำ Stark ให้กับโครงสร้างพื้นฐาน Lightning Network ของ OmniLayer

แนวคิดของการตรวจสอบฝั่งไคลเอ็นต์

เพื่อให้เข้าใจแนวคิดของการตรวจสอบฝั่งไคลเอ็นต์ เราต้องย้อนกลับไปในปีถัดจากการเกิดขึ้นของ Colored Coins และ Mastercoin ซึ่งก็คือปี 2013 ในปีนั้น Peter Todd ได้ตีพิมพ์บทความเรื่อง “Disentangling Crypto-Coin Mining: Timestamping, Proof-of-Publication, and Validation” แม้ว่าชื่อของบทความดูเหมือนจะไม่เกี่ยวข้องโดยตรงกับการตรวจสอบฝั่งไคลเอ็นต์ แต่การอ่านอย่างละเอียดพบว่าบทความนี้มีแนวคิดแรกสุดเกี่ยวกับการตรวจสอบความถูกต้องฝั่งไคลเอ็นต์

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

ตามความคิดของ Peter Todd ก่อนอื่นมาทำความเข้าใจปัญหาที่ BTC (Bitcoin) แก้ไขได้จริง ในมุมมองของ Peter Todd BTC สามารถแก้ไขปัญหาได้สามประการ:

หลักฐานการตีพิมพ์

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

ฉันทามติสั่งซื้อ

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

การตรวจสอบความถูกต้อง (ไม่บังคับ)

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

ณ จุดนี้ คุณอาจนึกถึง Ominilayer ที่กล่าวถึงข้างต้น Ominilayer เองไม่ได้มอบหมายการคำนวณและการตรวจสอบสถานะให้กับ BTC แต่ยังคงนำความปลอดภัยของ BTC มาใช้ซ้ำ ในทางกลับกัน Colored Coins มอบหมายการติดตามสถานะให้กับ BTC การมีอยู่ของทั้งสองแสดงให้เห็นว่าการตรวจสอบความถูกต้องไม่จำเป็นต้องเกิดขึ้นบนเครือข่าย

ดังนั้นการตรวจสอบฝั่งไคลเอ็นต์จะตรวจสอบธุรกรรมได้อย่างมีประสิทธิภาพอย่างไร

อันดับแรกเรามาดูกันว่าต้องมีการตรวจสอบอะไรบ้าง:

  • สถานะ (การตรวจสอบตรรกะของธุรกรรม)

  • ความถูกต้องของอินพุต TxIn (เพื่อป้องกันการใช้จ่ายซ้ำซ้อน)

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

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

Peter Todd เสนอโครงสร้างของแผนผังความมุ่งมั่นดังต่อไปนี้:

CTxIn -> CTxOut -> <เส้นทาง Merkle> <merkle path> -> CTransaction -> <เส้นทาง Merkle> <merkle path> -> CTxIn

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

ซีลแบบใช้ครั้งเดียว

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

สำหรับ SealProtocol มีสามองค์ประกอบและสองการดำเนินการ

องค์ประกอบพื้นฐาน:

  1. l: ประทับตรานั่นคือประทับตรา
  2. ม: ข้อความ ข้อความ
  3. ใน:พยาน, พยาน

การดำเนินงานขั้นพื้นฐาน: มีการดำเนินการพื้นฐานสองประการ:

  1. ปิด(l,m) → w: ในข้อความปิด messagemupper ให้สร้างพยานใน
  2. Verify(l,w,m) → bool: ยืนยัน sealall คุณอยู่ในข่าวหรือเปล่า?ปิดผิด

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

ประการแรก Single-Use Seal เป็นแนวคิดที่ทำให้แน่ใจว่าสินทรัพย์หรือข้อมูลบางอย่างจะถูกใช้หรือล็อคเพียงครั้งเดียวเท่านั้น ในบริบทของ Bitcoin โดยทั่วไปหมายความว่า UTXO (เอาต์พุตธุรกรรมที่ยังไม่ได้ใช้) สามารถใช้ได้เพียงครั้งเดียวเท่านั้น ดังนั้น เอาท์พุตของธุรกรรม Bitcoin จึงถือเป็นการปิดผนึกแบบครั้งเดียว และเมื่อเอาท์พุตนี้ถูกใช้เป็นอินพุตสำหรับธุรกรรมอื่น ซีลจะ "เสียหาย" หรือ "ถูกใช้งาน"

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

มันง่ายกว่านี้ได้ไหม?

ตราประทับแบบใช้ครั้งเดียว นั่นคือ blockchain ใด ๆ ถือเป็นฐานข้อมูล เราจัดเก็บคำสัญญาของข้อความบางอย่างไว้ในฐานข้อมูลนี้ในทางใดทางหนึ่ง และรักษาสถานะที่ใช้หรือที่จะถูกใช้งาน

ใช่ มันง่ายมาก

โดยสรุป สินทรัพย์ที่ลูกค้าตรวจสอบแล้วมีลักษณะดังต่อไปนี้:

  1. การจัดเก็บข้อมูลแบบออฟไลน์: ประวัติการทำธุรกรรม ความเป็นเจ้าของ และข้อมูลอื่น ๆ ที่เกี่ยวข้องส่วนใหญ่ของสินทรัพย์ที่ลูกค้าตรวจสอบจะถูกจัดเก็บแบบออฟไลน์ สิ่งนี้ช่วยลดความต้องการจัดเก็บข้อมูลออนไลน์ได้อย่างมากและช่วยปรับปรุงความเป็นส่วนตัว
  2. กลไกข้อผูกมัด: แม้ว่าข้อมูลสินทรัพย์จะถูกจัดเก็บแบบออฟไลน์ แต่การเปลี่ยนแปลงหรือถ่ายโอนข้อมูลนี้จะถูกบันทึกแบบออนไลน์ผ่านข้อผูกพัน ข้อผูกพันเหล่านี้ช่วยให้การทำธุรกรรมออนไลน์สามารถอ้างอิงสถานะนอกเครือข่ายได้ ดังนั้นจึงรับประกันความสมบูรณ์และการไม่เปลี่ยนแปลงข้อมูลนอกเครือข่าย
  3. พยานออนไลน์ (ไม่จำเป็นต้องเป็น BTC): แม้ว่าข้อมูลและการตรวจสอบส่วนใหญ่จะเป็นแบบออฟไลน์ แต่สินทรัพย์ที่ได้รับการยืนยันจากลูกค้ายังคงสามารถใช้ประโยชน์จากการรักษาความปลอดภัยของห่วงโซ่พื้นฐาน (การออกหลักฐาน การสั่งซื้อธุรกรรม) ผ่านข้อผูกพันที่ฝังอยู่ใน -โซ่.
  4. การยืนยันเสร็จสิ้นในฝั่งไคลเอ็นต์: งานการยืนยันส่วนใหญ่เสร็จสิ้นบนอุปกรณ์ของผู้ใช้ ซึ่งหมายความว่าโหนดเครือข่ายทั้งหมดไม่จำเป็นต้องมีส่วนร่วมในการตรวจสอบธุรกรรมแต่ละรายการ มีเพียงผู้เข้าร่วมที่เกี่ยวข้องเท่านั้นที่ต้องตรวจสอบความถูกต้องของธุรกรรม

สำหรับผู้ที่ใช้การตรวจสอบสินทรัพย์ฝั่งไคลเอ็นต์ มีอีกประเด็นที่ควรทราบ:

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

ผู้บุกเบิกในการตรวจสอบฝั่งไคลเอ็นต์ (CSV): RGB

แนวคิดของ RGB ได้รับการเสนอโดย Giacomo Zucco ซึ่งเป็นบุคคลที่มีชื่อเสียงในชุมชนหลังปี 2015 เนื่องจากการเพิ่มขึ้นของ Ethereum และการแพร่กระจายของ ICO และก่อน ICO ผู้คนจำนวนมากพยายามทำสิ่งต่าง ๆ นอกเหนือจาก Bitcoin เช่นโปรเจ็กต์ Mastercoin และ Colored Coins .

Giacomo Zucco แสดงความผิดหวัง เขาเชื่อว่าโครงการเหล่านี้ด้อยกว่า Bitcoin และเขาเชื่อว่าวิธีการนำโทเค็นไปใช้กับ Bitcoin ก่อนหน้านี้นั้นไม่เหมาะสม ในกระบวนการนี้ เขาได้พบกับ Peter Todd และรู้สึกทึ่งกับแนวคิดของ Peter Todd ในเรื่อง Client-Side-Validation จากนั้นเขาก็เริ่มเสนอแนวคิดRGB

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

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

กลไกความมุ่งมั่นของ RGB: Pedersen Hash

ในแง่ของกลไกความมุ่งมั่น RGB ใช้ Pedersen Hash ข้อได้เปรียบอยู่ที่ความสามารถในการยอมรับคุณค่าโดยไม่ต้องเปิดเผย การใช้ Pedersen Hash เพื่อสร้างแผนผัง Merkle หมายความว่าคุณสามารถสร้างแผนผัง Merkle ที่ได้รับการคุ้มครองความเป็นส่วนตัว ซึ่งจะซ่อนค่าต่างๆ ไว้ภายในต้นไม้นั้น โครงสร้างนี้สามารถใช้ในโปรโตคอลการป้องกันความเป็นส่วนตัวเฉพาะบางอย่าง เช่น โครงการสกุลเงินดิจิทัลที่ไม่ระบุตัวตนบางโครงการ อย่างไรก็ตาม อาจไม่เหมาะกับสินทรัพย์ CSV ซึ่งจะกล่าวถึงในภายหลังเมื่อเปรียบเทียบกับสินทรัพย์ Taproot

การออกแบบเครื่องเสมือนของ RGB: จากความเรียบง่ายไปจนถึง AluVM

RGB มีเป้าหมายไม่เพียงแต่จะใช้โปรโตคอลสินทรัพย์ที่ผ่านการตรวจสอบโดยไคลเอ็นต์เท่านั้น แต่ยังขยายไปสู่การดำเนินการเครื่องเสมือนและการเขียนโปรแกรมสัญญาของ Turing ที่สมบูรณ์อีกด้วย ในการออกแบบ RGB ในยุคแรกๆ อ้างว่าใช้ภาษาโปรแกรมที่เรียกว่า Simplicity ภาษานี้มีเอกลักษณ์เฉพาะด้วยการสร้างหลักฐานการดำเนินการในขณะที่ดำเนินการนิพจน์ ทำให้ง่ายต่อการตรวจสอบสัญญาที่เขียนไว้อย่างเป็นทางการ (เพื่อหลีกเลี่ยงข้อบกพร่อง) อย่างไรก็ตามการพัฒนาภาษานี้ไม่เหมาะและประสบปัญหาในที่สุด สิ่งนี้นำไปสู่การเกิดโปรโตคอล RGB ที่ยากลำบากในปีนั้นโดยตรง ท้ายที่สุดแล้ว RGB เริ่มใช้ AluVM ซึ่งพัฒนาโดย Maxim โดยมีเป้าหมายเพื่อหลีกเลี่ยงพฤติกรรมที่ไม่ได้กำหนดไว้ ซึ่งคล้ายกับความเรียบง่ายเริ่มแรก กล่าวกันว่า AluVM ใหม่จะถูกแทนที่ด้วยภาษาการเขียนโปรแกรมที่เรียกว่า Contractum ซึ่งปัจจุบันใช้ Rust ในอนาคต

ทิศทางการขยายเลเยอร์ 2 ของ RGB: Lightning Network หรือ Sidechain?

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

RGB และเครือข่ายสายฟ้า

พูดง่ายๆ ก็คือ หลักการของ Lightning Network คือทั้งสองฝ่ายที่เกี่ยวข้องในการทำธุรกรรมลงนามในสัญญา (ธุรกรรมที่มีข้อผูกพัน) นอกเครือข่าย สิ่งเหล่านี้ช่วยให้แน่ใจว่าหากฝ่ายใดฝ่ายหนึ่งฝ่าฝืนสัญญา ฝ่ายที่ได้รับความเดือดร้อนสามารถส่งสัญญา (ธุรกรรมข้อผูกพัน) ให้กับ BTC เพื่อการชำระหนี้ รับเงินของพวกเขา และลงโทษอีกฝ่าย กล่าวอีกนัยหนึ่ง Lightning Network รับประกันความปลอดภัยของธุรกรรมนอกเครือข่ายผ่านการออกแบบโปรโตคอลและทฤษฎีเกม

RGB สามารถสร้างโครงสร้างพื้นฐาน Lightning Network ของตัวเองได้โดยการออกแบบกฎสัญญาช่องทางการชำระเงินที่เหมาะกับตัวเอง แต่ความซับซ้อนของ Lightning Network นั้นสูงมาก และการสร้างระบบนี้ไม่ใช่เรื่องง่าย อย่างไรก็ตาม ในทางกลับกัน Lightnling Labs ได้ปลูกฝังสาขานี้มาหลายปีแล้ว และ LND มีส่วนแบ่งตลาดมากกว่า 90%

Sidechain ของ RGB: Prime

LNP-BP ซึ่งปัจจุบันรักษาโปรโตคอล RGB โดย Maxim จะออกข้อเสนอชื่อ Prime ในเดือนมิถุนายน 2023 ซึ่งเป็นแผนการขยายสินทรัพย์ที่ลูกค้าตรวจสอบแล้ว ในนั้นเขาได้วิพากษ์วิจารณ์ sidechain ที่มีอยู่และแผนการขยาย Lightning Network ว่าซับซ้อนเกินไปในการพัฒนา Maxim ระบุว่าเขาเชื่อว่านอกเหนือจาก Prime แล้ว วิธีการขยายอื่นๆ ยังรวมถึง NUCLEUS multi-node Lightning channel และโรงงาน Ark/Enigma channel ซึ่งทั้งสองวิธีนี้ต้องใช้เวลาในการพัฒนามากกว่าสองปี อย่างไรก็ตาม Prime สามารถแล้วเสร็จได้ภายในเวลาเพียงหนึ่งปี

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

  1. บริการประทับเวลา: การกำหนดลำดับธุรกรรมภายในเวลาเพียง 10 วินาที

  2. หลักฐาน: จัดเก็บในรูปแบบ PMT ผลิตและเผยแพร่พร้อมกับส่วนหัวของบล็อก

  3. การประทับตราแบบครั้งเดียว: โปรโตคอลการประทับตราแบบนามธรรมแบบครั้งเดียว ซึ่งรับประกันการป้องกันการใช้จ่ายซ้ำซ้อน หากใช้งานบน Bitcoin ก็สามารถเชื่อมโยงกับ UTXO ได้ ซึ่งคล้ายกับการออกแบบ RGB ในปัจจุบัน

  4. โปรโตคอลสัญญาอัจฉริยะ: สัญญาที่แบ่งส่วนได้ - RGB (เปลี่ยนได้)

เพื่อแก้ไขปัญหาเวลายืนยันธุรกรรม RGB Prime ใช้บริการประทับเวลาเพื่อยืนยันธุรกรรมนอกเครือข่ายอย่างรวดเร็วและสรุปธุรกรรมและ ID ลงในบล็อก ในขณะเดียวกัน หลักฐานการทำธุรกรรมบน Prime สามารถรวมเพิ่มเติมผ่าน PMT จากนั้นจึงยึดกับ BTC ในลักษณะที่คล้ายกับจุดตรวจ

โปรโตคอลสินทรัพย์ CSV ที่ใช้ Taproot: สินทรัพย์ Taproot

Taproot Assets เป็นโปรโตคอลสินทรัพย์ CSV ที่ใช้ Taproot ซึ่งใช้ในการออกสินทรัพย์ที่ลูกค้าตรวจสอบแล้วบนบล็อกเชน Bitcoin สินทรัพย์เหล่านี้สามารถซื้อขายได้ทันทีในปริมาณมากด้วยต้นทุนที่ต่ำผ่าน Lightning Network หัวใจสำคัญของ Taproot Assets อยู่ที่การใช้ประโยชน์จากความปลอดภัยและความเสถียรของเครือข่าย Bitcoin ตลอดจนความเร็ว ความสามารถในการขยายขนาด และต้นทุนต่ำของ Lightning Network โปรโตคอลนี้ได้รับการออกแบบและพัฒนาโดย CTO ของ Lightnling Labs ซึ่งอาจเป็นบุคคลเพียงคนเดียวบนโลกใบนี้ที่เป็นผู้นำการพัฒนาทั้งไคลเอนต์ Bitcoin (BTCD) และไคลเอนต์ Lightning Network (LND) เป็นการส่วนตัว และมีความเข้าใจอย่างลึกซึ้ง ของ BTC

ธุรกรรมของ Taproot มีเพียงแฮชรูทของสคริปต์เนื้อหาเท่านั้น ทำให้ยากสำหรับผู้สังเกตการณ์ภายนอกในการระบุว่าเกี่ยวข้องกับทรัพย์สินของ Taproot หรือไม่ เนื่องจากแฮชนั้นเป็นข้อมูลทั่วไปและสามารถแสดงข้อมูลใดๆ ได้ ด้วยการอัพเกรด Taproot Bitcoin ได้รับความสามารถของสัญญาอัจฉริยะ (TapScript) ด้วยเหตุนี้ การเข้ารหัสสินทรัพย์ของ Taproot Assets จึงคล้ายกับการสร้างคำจำกัดความโทเค็นที่คล้ายกับ ERC20 หรือ ERC721 ดังนั้น Bitcoin ไม่เพียงแต่มีหน้าที่ในการกำหนดสินทรัพย์เท่านั้น แต่ยังมีความสามารถในการเขียนสัญญาอัจฉริยะ ซึ่งเป็นการวางรากฐานสำหรับโครงสร้างพื้นฐานสัญญาอัจฉริยะของโทเค็นบน Bitcoin

โครงสร้างการเข้ารหัสของ Taproot Assets มีดังนี้: [คำอธิบายสิ้นสุดที่นี่ ซึ่งระบุส่วนถัดไปของบทความที่น่าจะเจาะลึกรายละเอียดทางเทคนิคของโครงสร้างการเข้ารหัสของ Taproot Assets]

รูปภาพโดย Lightning Labs CTO เนื้อย่าง

เนื่องจากเป็นโปรโตคอลสินทรัพย์ CSV (CoinSwap) สินทรัพย์ Taproot ได้รับการออกแบบให้มีความคล่องตัวมากกว่าเมื่อเทียบกับ RGB พวกเขาใช้ความก้าวหน้าในปัจจุบันให้เกิดประโยชน์สูงสุดในระบบนิเวศ BTC เช่นการอัพเกรด Taproot และ PSBT (ธุรกรรม Bitcoin ที่ลงนามบางส่วน) ความแตกต่างที่สำคัญที่สุดระหว่าง Taproot Assets และ RGB ในแง่ของความสามารถในการขยายแอปพลิเคชันอยู่ที่การดำเนินการ VM (Virtual Machine) Taproot Assets ใช้ TaprootScriptVM ซึ่งเหมือนกับ VM ดั้งเดิมที่ใช้โดย BTC ในช่วงไม่กี่ปีที่ผ่านมา การศึกษาโครงสร้างพื้นฐานจำนวนมากสำหรับ BTC ได้อิงจาก TapScript อย่างไรก็ตาม เนื่องจากการอัพเกรด BTC เป็นไปอย่างช้าๆ การศึกษาเหล่านี้จึงไม่ได้ดำเนินการอย่างรวดเร็ว ทำให้ Taproot Assets กลายเป็นพื้นที่ทดสอบที่มีศักยภาพสำหรับแนวคิดใหม่เหล่านี้

Taproot Assets และ RGB แตกต่างกันอย่างไร

  1. การตรวจสอบธุรกรรมและความเป็นมิตรของ Light Node

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

  1. การดำเนินการ VM

Taproot Assets เกิดขึ้นหลังจากการอัพเกรด Taproot พวกเขาใช้ TaprootScriptVM ซึ่งเป็นเอ็นจิ้นการเรียกใช้สคริปต์ที่มีอยู่ในการอัพเกรด Bitcoin หลัง Taproot และ vPSBT ซึ่งเป็นรูปแบบหนึ่งของ PSBT ของ BTC เมื่อกลไกช่องสัญญาณฟ้าผ่าของ Taproot Assets เสร็จสมบูรณ์ จะสามารถนำโครงสร้างพื้นฐาน LND ในปัจจุบันทั้งหมดและผลิตภัณฑ์ Lightning Labs ที่ผ่านมากลับมาใช้ใหม่ได้ทันที (ปัจจุบัน LND ครองเครือข่าย Lightning มากกว่า 90%) ข้อเสนอ BitVM ล่าสุด ซึ่งใช้ TaprootScript เช่นกัน ก็สนับสนุน Taproot Assets ในทางทฤษฎี อย่างไรก็ตาม VM ของ RGB และกฎการตรวจสอบ (SCHEMA) นั้นมีอยู่ในตัวเอง ก่อให้เกิดระบบนิเวศที่ค่อนข้างปิด การพัฒนาของ RGB นั้นส่วนใหญ่ถูกจำกัดอยู่ในระบบนิเวศของมัน และการบูรณาการเข้ากับระบบนิเวศของ Bitcoin นั้นไม่ได้ใกล้เคียงอย่างที่คิด ตัวอย่างเช่น ความสัมพันธ์เพียงอย่างเดียวของ RGB กับการอัปเกรด Taproot คือการเข้ารหัสข้อมูลความมุ่งมั่นของลูกโซ่ลงใน TapLeaf ของ Witness

  1. สัญญาอัจฉริยะ

ในการใช้งานปัจจุบันของ RGB สัญญาและ VM ได้รับการเน้นย้ำอย่างมาก อย่างไรก็ตาม สัญญาอัจฉริยะยังไม่ปรากฏใน Taproot Assets ในปัจจุบัน RGB ไม่ได้อธิบายว่าการปรับเปลี่ยน Global State ซิงโครไนซ์กับส่วนสัญญาแต่ละรายการ (UTXO) อย่างไร และวิธีที่ Pedersen Commitment ซึ่งรับรองเฉพาะปริมาณสินทรัพย์ทั้งหมดเท่านั้น จะตรวจจับการปลอมแปลงกับรัฐอื่นๆ ได้อย่างไร ในทางตรงกันข้าม Taproot Assets ซึ่งมีการออกแบบที่เรียบง่ายกว่า ปัจจุบันจัดเก็บเฉพาะยอดคงเหลือของสินทรัพย์เท่านั้น และไม่มีพื้นที่จัดเก็บที่กว้างขวาง ส่งผลให้การอภิปรายเกี่ยวกับสัญญาอัจฉริยะเกิดก่อนเวลาอันควร อย่างไรก็ตาม Lightning Labs ระบุว่า Taproot Assets จะมุ่งเน้นไปที่การออกแบบสัญญาอัจฉริยะในปีหน้า

  1. ศูนย์กลางการซิงโครไนซ์

ตามที่เข้าใจจากหลักการพื้นฐานของการตรวจสอบสินทรัพย์ฝั่งไคลเอ็นต์ การถือหลักฐานมีความสำคัญพอๆ กับการถือกุญแจส่วนตัว แต่จะเกิดอะไรขึ้นถ้า Proof หายไปในฝั่งไคลเอ็นต์ของผู้ใช้? ใน Taproot Assets ปัญหานี้สามารถแก้ไขได้ผ่าน 'จักรวาล' จักรวาลเป็นต้นไม้ Merkle กระจัดกระจายที่สาธารณชนตรวจสอบได้ ซึ่งครอบคลุมทรัพย์สินตั้งแต่หนึ่งรายการขึ้นไป จักรวาลไม่ได้โฮสต์ทรัพย์สินของ Taproot ซึ่งแตกต่างจากแผนผังทรัพย์สินของ Taproot ทั่วไป แต่จะผูกพันกับชุดย่อยของประวัติสินทรัพย์ตั้งแต่หนึ่งรายการขึ้นไป ใน RGB บทบาทนี้เล่นโดย Storm ซึ่งจะซิงโครไนซ์ข้อมูลการพิสูจน์นอกเชนผ่าน P2P อย่างไรก็ตาม เนื่องจากเหตุผลทางประวัติศาสตร์ของทีมพัฒนา RGB รูปแบบการพิสูจน์เหล่านี้จึงเข้ากันไม่ได้ในปัจจุบัน มีรายงานว่าทีมระบบนิเวศของ RGB DIBA กำลังพัฒนา 'คาร์บอนาโด' เพื่อแก้ไขปัญหานี้ แม้ว่าความคืบหน้าจะไม่ชัดเจนก็ตาม

  1. การดำเนินการทางวิศวกรรม

ไลบรารีทั้งหมดที่ใช้โดย Taproot Assets ผ่านการทดสอบตามเวลา เนื่องจาก Lightning Labs มีไคลเอนต์ Bitcoin (BTCD), ไคลเอนต์เครือข่าย Lightning (LND) และการใช้งาน Wallet lib มากมาย ในทางตรงกันข้าม ไลบรารีส่วนใหญ่ที่ใช้ใน RGB นั้นถูกกำหนดด้วยตนเอง และจากมุมมองมาตรฐานอุตสาหกรรม การใช้งาน RGB ยังอยู่ในขั้นทดลอง”

การอภิปรายสั้น ๆ เกี่ยวกับอนาคตของการขยาย BTC

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

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

การคำนวณแบบ on-chain น้อยลง, การตรวจสอบความถูกต้องแบบ on-chain มากขึ้น

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

การตรวจสอบความถูกต้องเกิดขึ้นที่ไหน? นี้เป็นสิ่งสำคัญ

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

จากมุมมองของการดำเนินการตรวจสอบ เรามีแนวทางในการขยาย 3 ประการ:

  1. 1. การตรวจสอบแบบออนไลน์ (OP-ZKP)
  2. หาก OP-ZKP ถูกนำไปใช้โดยตรงใน TaprootScriptVM นั่นหมายถึงการบูรณาการความสามารถในการตรวจสอบ ZKP เข้ากับ BTC เอง ควบคู่ไปกับการออกแบบ Covenant บางประการสำหรับโปรโตคอลการชำระเงิน สร้างแผนการขยาย Zk-Rollup ที่สืบทอดความปลอดภัยของ BTC อย่างไรก็ตาม กระบวนการอัปเกรดที่ช้าของ BTC ควบคู่ไปกับการใช้ op-code เฉพาะทางและอาจจำเป็นต้องอัปเกรดนั้น ต่างจากการใช้สัญญาการตรวจสอบความถูกต้องบน Ethereum ทำให้เกิดความท้าทาย
  3. 2. การตรวจสอบแบบกึ่งออนเชน (BitVM)
  4. การออกแบบ BitVM ไม่ได้มีไว้เพื่อรองรับตรรกะธุรกรรมปกติ Robin Linus ยังระบุด้วยว่าอนาคตของ BitVM อยู่ที่การสร้างตลาด cross-chain ฟรีสำหรับ SideChains ต่างๆ แนวทางของ BitVM ถือเป็นแบบกึ่งออนเชน เนื่องจากการคำนวณการตรวจสอบเหล่านี้ส่วนใหญ่ไม่ได้เกิดขึ้นแบบออนเชน แต่เป็นแบบออฟไลน์ อย่างไรก็ตาม เหตุผลสำคัญในการออกแบบ Taproot ของ BTC คือการใช้ TapScriptVM สำหรับการตรวจสอบความถูกต้องทางคอมพิวเตอร์เมื่อจำเป็น โดยในทางทฤษฎีจะสืบทอดความปลอดภัยของ BTC กระบวนการนี้ยังสร้างห่วงโซ่ความน่าเชื่อถือในการตรวจสอบความถูกต้องด้วย ตัวอย่างเช่น ก็เพียงพอแล้วหากหนึ่งในเครื่องมือตรวจสอบความถูกต้อง 'n' มีความซื่อสัตย์ คล้ายกับการสรุปเชิงบวก
  5. ต้นทุนออนไลน์ของ BitVM นั้นสูง แต่สามารถใช้หลักฐานการฉ้อโกง ZK เพื่อการปรับปรุงประสิทธิภาพได้หรือไม่ คำตอบคือไม่ เนื่องจากการนำหลักฐานการฉ้อโกงของ ZK ไปใช้นั้นขึ้นอยู่กับความสามารถในการตรวจสอบความถูกต้องของ ZKP แบบออนไลน์ ซึ่งนำเรากลับไปสู่ภาวะที่กลืนไม่เข้าคายไม่ออกของโครงการ OP-ZKP
  6. 3. การตรวจสอบความถูกต้องแบบ Off-chain (การตรวจสอบความถูกต้องฝั่งไคลเอ็นต์, เครือข่าย Lightning)
  7. เมื่อการตรวจสอบความถูกต้องเกิดขึ้นนอกเครือข่ายทั้งหมด เราจะกลับไปสู่โปรโตคอลสินทรัพย์ CSV และ Lightning Network ที่กล่าวถึงก่อนหน้านี้ ในการสนทนาก่อนหน้านี้ สังเกตว่าในการออกแบบ CSV เราไม่สามารถป้องกันการปลอมแปลงที่สมรู้ร่วมคิดได้อย่างสมบูรณ์ สิ่งที่เราทำได้คือใช้การเข้ารหัสและการออกแบบโปรโตคอลเพื่อรักษาความเสียหายจากการสมรู้ร่วมคิดที่เป็นอันตรายให้อยู่ภายในขอบเขตที่ควบคุมได้ ทำให้พฤติกรรมดังกล่าวไม่เกิดประโยชน์
  8. ข้อดีและข้อเสียของการตรวจสอบความถูกต้องแบบออฟไลน์มีความชัดเจน ข้อได้เปรียบคือการใช้ทรัพยากรออนไลน์น้อยที่สุด และมีศักยภาพในการขยายอย่างมาก ข้อเสียคือแทบเป็นไปไม่ได้เลยที่จะใช้ประโยชน์จากการรักษาความปลอดภัยของ BTC ได้อย่างเต็มที่ โดยจำกัดประเภทและวิธีการของธุรกรรมนอกเครือข่ายอย่างมาก นอกจากนี้ การตรวจสอบความถูกต้องแบบออฟไลน์ยังหมายความว่าข้อมูลจะถูกเก็บไว้แบบออฟไลน์ โดยมีการจัดการโดยผู้ใช้ ซึ่งต้องการข้อกำหนดที่สูงขึ้นสำหรับความปลอดภัยของสภาพแวดล้อมการทำงานของซอฟต์แวร์และความเสถียรของซอฟต์แวร์

แนวโน้มวิวัฒนาการการขยายตัว

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

ข้อสงวนสิทธิ์:

  1. บทความนี้พิมพ์ซ้ำจาก [กระจกเงา] ลิขสิทธิ์ทั้งหมดเป็นของผู้แต่งต้นฉบับ [Ben77] หากมีการคัดค้านการพิมพ์ซ้ำนี้ โปรดติดต่อทีมงาน Gate Learn แล้วพวกเขาจะจัดการโดยเร็วที่สุด
  2. การปฏิเสธความรับผิด: มุมมองและความคิดเห็นที่แสดงในบทความนี้เป็นเพียงของผู้เขียนเท่านั้น และไม่ถือเป็นคำแนะนำในการลงทุนใดๆ
  3. การแปลบทความเป็นภาษาอื่นดำเนินการโดยทีมงาน Gate Learn เว้นแต่จะกล่าวถึง ห้ามคัดลอก แจกจ่าย หรือลอกเลียนแบบบทความที่แปลแล้ว
เริ่มตอนนี้
สมัครและรับรางวัล
$100