คำนำ

การออกสินทรัพย์ตาม BTC ถือเป็นประเด็นร้อนมาโดยตลอด ตั้งแต่ Colored Coins ที่เก่าแก่ที่สุดในปี 2011 ไปจนถึงโปรโตคอล Ordinal ที่ได้รับความนิยมเมื่อเร็ว ๆ นี้ ชุมชน BTC สามารถสร้างผู้เล่นใหม่ ๆ และฉันทามติได้อย่างต่อเนื่อง แต่มีเพียงไม่กี่คนที่ติดอยู่ อย่างไรก็ตาม Lightning Labs ได้เปิดเผยแผนการอันทะเยอทะยานในการพัฒนา Stablecoins โดยอิงจาก Taproot Assets Tether ยังประกาศด้วยว่าจะใช้โปรโตคอล RGB สำหรับการขุด USDT บนเลเยอร์ 1 ของ Bitcoin

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

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

เหรียญสี

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

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

Colored Coins เป็นโปรโตคอลที่ออกแบบมาเพื่อการออกสินทรัพย์บนบล็อกเชน Bitcoin มันดำเนินการโดยการ "ระบายสี" เศษส่วนเฉพาะของ bitcoin เพื่อบ่งบอกถึงสินทรัพย์อื่น ๆ Bitcoins ที่ทำเครื่องหมายไว้เหล่านี้ยังคงรักษาฟังก์ชันการทำงานดั้งเดิมไว้ แต่ยังแสดงถึงสินทรัพย์หรือมูลค่าอื่นอีกด้วย อย่างไรก็ตาม คำถามสำคัญก็คือ แนวคิดนี้สามารถเกิดขึ้นจริงบนเครือข่าย Bitcoin ได้อย่างไร

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

ผลลัพธ์มีลักษณะดังนี้:

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

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

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

ICO แรกใน Crypto: Mastercoin

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

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

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

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

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

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

สรุป:

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

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

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

หากเราต้องการเข้าใจแนวคิดของ Client Side Validation (CSV) เราต้องย้อนกลับไปในปีถัดจากการเกิดขึ้นของ Colored Coins และ Mastercoin ซึ่งก็คือปี 2013 ในปีนั้น Peter Todd นักวิจัย Bitcoin และการเข้ารหัสในยุคแรกๆ ได้เผยแพร่บทความเรื่อง “การแยกส่วนการขุด Crypto-Coin: การประทับเวลา การพิสูจน์การตีพิมพ์ และการตรวจสอบความถูกต้อง”“ แม้ว่าชื่อเรื่องจะไม่ได้กล่าวถึงการตรวจสอบฝั่งไคลเอ็นต์อย่างชัดเจน แต่การอ่านอย่างละเอียดพบว่านี่เป็นหนึ่งในงานเขียนชิ้นแรกๆ ที่จะแนะนำแนวคิดนี้

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

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

1. Proof-of-publication: สาระสำคัญของ Proof-of-publication คือการแก้ปัญหาการใช้จ่ายซ้ำซ้อน ตัวอย่างเช่น หาก Alice ต้องการโอน bitcoin บางส่วนให้กับ Bob แม้ว่าเธอจะลงนามในธุรกรรมเพื่อโอนให้กับ Bob แล้ว Bob ก็อาจไม่รู้ทางกายภาพว่ามีธุรกรรมดังกล่าวอยู่ ดังนั้นเราจึงจำเป็นต้องมีสถานที่สาธารณะเพื่อเผยแพร่ธุรกรรม และทุกคนสามารถสืบค้นธุรกรรมได้จากที่นั่น
2. ฉันทามติในการสั่งซื้อ: ในระบบคอมพิวเตอร์ เวลาทางกายภาพที่เรามักจะประสบนั้นไม่มีอยู่จริง ในระบบแบบกระจาย เวลามักจะเป็นการประทับเวลาของแลมพอร์ต ซึ่งไม่ได้ให้การวัดเวลาทางกายภาพของเรา แต่จัดลำดับธุรกรรมของเรา
3. การตรวจสอบ (ไม่บังคับ): การตรวจสอบความถูกต้องของ Bitcoin เกี่ยวข้องกับการตรวจสอบลายเซ็นและจำนวนเงินที่โอนในธุรกรรม BTC อย่างไรก็ตาม Peter Todd เชื่อว่าการตรวจสอบนี้ไม่จำเป็นสำหรับการสร้างระบบโทเค็นที่อยู่ด้านบนของ Bitcoin มันเป็นเพียงตัวเลือกการเพิ่มประสิทธิภาพ

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

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

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

1. สถานะ (การตรวจสอบลอจิกธุรกรรม)
2. ตรวจสอบว่าอินพุต (TxIn) ถูกต้องเพื่อป้องกันการใช้จ่ายซ้ำซ้อน

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

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

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

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

แต่เราจะจัดเก็บ Commitment Tree ไว้บน Blockchain ได้อย่างไร? นี่คือจุดที่เราสามารถแนะนำแนวคิดของ "ตราประทับแบบใช้ครั้งเดียว"

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

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

สำหรับ SealProtocol มีสามองค์ประกอบและสองการกระทำ

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

1. ล: ประทับตรา
2. m : ข้อความ ซึ่งเป็นข้อมูลหรือธุรกรรม
3. w: พยาน บุคคลหรือบางสิ่งบางอย่างที่สามารถตรวจสอบตราประทับได้

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

1. ปิด(l, m) → w: ปิดตราประทับ l บนข้อความ m เพื่อให้เป็นพยาน w
2. Verify(l, w, m) → bool: ตรวจสอบว่าซีล l ถูกปิดในข้อความ m หรือไม่

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

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

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

เพื่อให้ง่ายยิ่งขึ้น:

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

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

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

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

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

RGB ผู้บุกเบิก CSV

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

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

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

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

กลไกความมุ่งมั่นที่ใช้ใน RGB, Pedersen Hash

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

การออกแบบเครื่องเสมือนเพื่อความเรียบง่าย RGB → AluVM

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

ทิศทางสเกล RGB layer2: Lightning network หรือ Sidechain?

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

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

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

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

Sidechain Prime ของ RGB

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

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

1. บริการประทับเวลา: บริการนี้สามารถสรุปลำดับธุรกรรมได้ในเวลาเพียง 10 วินาที
2. ข้อพิสูจน์: สิ่งเหล่านี้ถูกจัดเก็บในรูปแบบของ Partial Merkle Trees (PMTs) และผลิตและเผยแพร่ควบคู่ไปกับส่วนหัวของบล็อก
3. ซีลแบบใช้ครั้งเดียว: นี่เป็นโปรโตคอลซีลแบบใช้ครั้งเดียวที่เป็นนามธรรมซึ่งออกแบบมาเพื่อป้องกันการใช้จ่ายซ้ำซ้อน เมื่อนำมาใช้กับ Bitcoin จะสามารถเชื่อมโยงกับ UTXO ได้ ซึ่งคล้ายกับการออกแบบ RGB ในปัจจุบัน
4. Smart Contract Protocol: สัญญาแบบแบ่งส่วนสำหรับ RGB (ซึ่งสามารถแทนที่ได้)

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

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

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

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

โครงสร้างการเข้ารหัสของ Taproot Assets เป็นดังนี้:

โดย roasbeef, CTO ของ Lighting Labs

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

ความแตกต่างระหว่างสินทรัพย์ Taproot และ RGB

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

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

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

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

อย่างไรก็ตาม RGB ทำงานแตกต่างออกไปบ้าง เครื่องเสมือนและกฎการตรวจสอบ (SCHEMA) เป็นส่วนหนึ่งของระบบที่มีในตัวเอง ซึ่งก่อให้เกิดระบบนิเวศที่ค่อนข้างปิด RGB ดำเนินการภายในระบบนิเวศของตัวเอง และความสัมพันธ์กับระบบนิเวศ Bitcoin ในวงกว้างนั้นไม่ได้ใกล้เคียงอย่างที่บางคนคิด ตัวอย่างเช่น ในส่วนของการอัพเกรด Taproot การโต้ตอบที่แท้จริงเพียงอย่างเดียวของ RGB คือการเข้ารหัสข้อมูลความมุ่งมั่นลงบนบล็อกเชนใน Witness TapLeaf นี่แสดงให้เห็นว่าการอัพเกรด RGB และ Taproot มีการเชื่อมต่อเพียงเล็กน้อยเท่านั้น

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

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

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

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

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

ในระบบ RGB บทบาทนี้ได้รับการเติมเต็มโดย Storm ซึ่งจะซิงโครไนซ์ข้อมูลการพิสูจน์นอกเชนผ่านเครือข่ายเพียร์ทูเพียร์ (p2p) อย่างไรก็ตาม เนื่องจากเหตุผลทางประวัติศาสตร์ที่เกี่ยวข้องกับทีมพัฒนา RGB ทีมเหล่านี้จึงใช้รูปแบบการพิสูจน์ที่เข้ากันไม่ได้ในปัจจุบัน DIBA ทีมระบบนิเวศ RGB ระบุว่าจะพัฒนา "คาร์บอนไดออกไซด์ " เพื่อแก้ไขปัญหานี้ แต่ความคืบหน้ายังไม่ชัดเจน

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

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

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

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

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

การคำนวณแบบออนไลน์น้อยลง, การตรวจสอบแบบออนไลน์ที่มากขึ้น

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

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

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

จากมุมมองของการใช้งานตามการยืนยัน เรามีสามแนวทางในการปรับขนาด:

1. การตรวจสอบออนไลน์ (OP-ZKP)

การใช้ OP-ZKP โดยตรงใน TaprootScriptVM จะทำให้ Bitcoin มีความสามารถในการตรวจสอบ ZKP ได้ เมื่อรวมกับโปรโตคอลการชำระเงินการออกแบบ Covenant สามารถสร้างโซลูชันการปรับขนาด Zk-Rollup ที่สืบทอดความปลอดภัยของ Bitcoin อย่างไรก็ตาม ต่างจากการปรับใช้สัญญาการตรวจสอบบน Ethereum ตรงที่การอัพเกรดของ Bitcoin นั้นช้าโดยธรรมชาติ และการเพิ่ม op-code เฉพาะทางที่อาจจำเป็นต้องอัปเกรดนั้นถือเป็นเรื่องท้าทาย

2. การตรวจสอบแบบกึ่งออนเชน (BitVM)

การออกแบบ BitVM ช่วยให้มั่นใจได้ว่าไม่ได้มีไว้สำหรับตรรกะธุรกรรมทั่วไป Robin Linus ยังระบุด้วยว่าอนาคตของ BitVM อยู่ที่การสร้างตลาด cross-chains ฟรีสำหรับ SideChains ต่างๆ แนวทางของ BitVM ถือเป็นแบบกึ่งออนเชน เนื่องจากการคำนวณการตรวจสอบส่วนใหญ่จะไม่เกิดขึ้นแบบออนเชน แต่จะเป็นแบบออฟไลน์ เหตุผลสำคัญในการออกแบบ Taproot ของ Bitcoin คือการใช้ TapScriptVM สำหรับการตรวจสอบทางคอมพิวเตอร์เมื่อจำเป็น ซึ่งในทางทฤษฎีจะสืบทอดความปลอดภัยของ Bitcoin กระบวนการนี้ยังสร้างห่วงโซ่ความน่าเชื่อถือในการตรวจสอบ เช่น ต้องการเพียงผู้ตรวจสอบที่ซื่อสัตย์เพียงคนเดียวเท่านั้นในบรรดาผู้ตรวจสอบ 'n' หรือที่เรียกว่า Optimistic Rollups

BitVM มีค่าใช้จ่าย on-chain จำนวนมาก แต่สามารถใช้หลักฐานการฉ้อโกง ZK เพื่อเพิ่มประสิทธิภาพได้หรือไม่? คำตอบคือไม่ เนื่องจากการนำหลักฐานการฉ้อโกงของ ZK ไปใช้นั้นขึ้นอยู่กับความสามารถในการตรวจสอบ ZKP แบบออนไลน์ ซึ่งนำเรากลับไปสู่ความยากลำบากของแนวทาง OP-ZKP

3. การตรวจสอบนอกเครือข่าย (การตรวจสอบฝั่งไคลเอ็นต์, เครือข่าย Lightning)

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

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

แนวโน้มวิวัฒนาการของการปรับขนาด

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

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

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