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

โปรโตคอล RGB: ผู้ใช้ต้องยืนยันข้อมูลด้วยตนเอง

RGB Protocol เป็นโปรโตคอลสินทรัพย์ P2P ชนิดพิเศษซึ่งทํางานภายใต้ระบบการคํานวณของ Bitcoin chain ในบางวิธีก็คล้ายกับช่องทางการชําระเงิน: ผู้ใช้ต้องเรียกใช้ลูกค้าเป็นการส่วนตัวและตรวจสอบการดําเนินการโอนที่เกี่ยวข้องกับตัวเอง ("ยืนยันด้วยตัวเอง") แม้ว่าคุณจะเป็นเพียงผู้รับสินทรัพย์ แต่คุณต้องยืนยันก่อนว่าใบแจ้งยอดการโอนจากผู้ส่งถูกต้องก่อนที่การโอนจะมีผล วิธีการนี้เรียกว่า "การโอนแบบโต้ตอบ" นั้นแตกต่างจากวิธีการโอนและรับสินทรัพย์แบบดั้งเดิมอย่างชัดเจน ทําไมสิ่งนี้จึงจําเป็น เหตุผลก็คือโปรโตคอล RGB เพื่อปกป้องความเป็นส่วนตัวไม่ได้ใช้ "โปรโตคอลฉันทามติ" ที่พบในบล็อกเชนแบบดั้งเดิมเช่น Bitcoin และ Ethereum (ซึ่งข้อมูลเมื่ออยู่ในโปรโตคอลฉันทามติจะถูกสังเกตโดยโหนดเกือบทั้งหมดในเครือข่ายทําให้ความเป็นส่วนตัวยากที่จะปกป้อง) หากไม่มีกระบวนการฉันทามติที่เกี่ยวข้องกับโหนดจํานวนมากการเปลี่ยนแปลงสินทรัพย์จะมั่นใจได้อย่างไรว่าปลอดภัย? นี่คือที่มาของแนวคิดเรื่อง "การยืนยันลูกค้า" ("ยืนยันด้วยตัวเอง") คุณต้องเรียกใช้ลูกค้าของคุณและตรวจสอบการเปลี่ยนแปลงสินทรัพย์ที่เกี่ยวข้องกับคุณเป็นการส่วนตัว

ตัวอย่างเช่นลองพิจารณาผู้ใช้ RGB ชื่อ Bob ที่รู้จักอลิซ อลิซต้องการโอนโทเค็น TEST 100 โทเค็นให้กับบ็อบ หลังจากสร้างข้อมูลการถ่ายโอน "Alice to Bob" อลิซจะส่งข้อมูลการถ่ายโอนและข้อมูลทรัพย์สินที่เกี่ยวข้องไปยัง Bob เพื่อให้เขาตรวจสอบเป็นการส่วนตัว เฉพาะเมื่อ Bob ยืนยันว่าทุกอย่างถูกต้องการถ่ายโอนจะกลายเป็นการถ่ายโอน RGB ที่ถูกต้อง ดังนั้นโปรโตคอล RGB ต้องการให้ผู้ใช้ตรวจสอบความถูกต้องของข้อมูลด้วยตนเองแทนที่อัลกอริทึมฉันทามติแบบเดิม อย่างไรก็ตามหากไม่มีฉันทามติข้อมูลที่ได้รับและจัดเก็บโดยไคลเอนต์ RGB ที่แตกต่างกันจะไม่สอดคล้องกัน ทุกคนจัดเก็บข้อมูลสินทรัพย์ที่เกี่ยวข้องกับตัวเองในพื้นที่เท่านั้นและไม่รู้เกี่ยวกับสถานะสินทรัพย์ของผู้อื่น แม้ว่าจะปกป้องความเป็นส่วนตัว แต่ก็สร้าง "เกาะข้อมูล" ด้วย หากมีคนอ้างว่ามีโทเค็น TEST 1 ล้านโทเค็นและต้องการโอนเงิน 100,000 ให้คุณคุณจะไว้วางใจพวกเขาได้อย่างไร? ในเครือข่าย RGB หากมีคนต้องการโอนสินทรัพย์ให้คุณพวกเขาจะต้องแสดงหลักฐานสินทรัพย์ก่อนติดตามประวัติของสินทรัพย์ตั้งแต่การออกครั้งแรกไปจนถึงการโอนหลายครั้งเพื่อให้แน่ใจว่าโทเค็นที่พวกเขาต้องการโอนให้คุณนั้นถูกต้องตามกฎหมาย มันเหมือนกับเมื่อคุณได้รับธนบัตรที่ไม่สามารถอธิบายได้คุณขอให้ผู้ส่งอธิบายประวัติของธนบัตรเหล่านี้ไม่ว่าจะออกโดยผู้ออกที่กําหนดเพื่อหลีกเลี่ยงเงินปลอม

(Image source: Coinex)

กระบวนการด้านบนเกิดขึ้นภายใต้เชื่อมต่อ Bitcoin chain และขั้นตอนเหล่านี้เพียงอย่างเดียวไม่เป็นการสร้างความเชื่อมต่อโดยตรงระหว่าง RGB และเครือข่าย Bitcoin หากต้องการแก้ไขปัญหานี้ RGB protocol ใช้แนวคิดของ "single-use seals" ซึ่งเชื่อมโยงทรัพย์สิน RGB กับ UTXOs (Unspent Transaction Outputs) บน Bitcoin chain ในขณะที่ UTXO ของ Bitcoin ยังไม่ได้ถูกใช้ให้ครั้งที่สอง ทรัพย์สิน RGB ที่ผูกไว้จะไม่ได้รับการชำระเงินครั้งที่สอง ซึ่งเชื่อมโยงกับเครือข่าย Bitcoin เพื่อป้องกัน "Re-organization" ของทรัพย์สิน RGB แน่นอน สิ่งนี้ต้องการการเผยแพร่ของ Commitments บน Bitcoin chain และการใช้งานของ OP_Return opcode

Let’s outline the workflow of the RGB protocol:

1. ทรัพย์สิน RGB ผูกติดกับ Bitcoin UTXOs และบ็อบเป็นเจ้าของ Bitcoin UTXOs บางส่วน อลิซต้องการโอนโทเค็น 100 ให้บ็อบ ก่อนที่จะได้รับทรัพย์สิน บ็อบแจ้งให้อลิซทราบว่า Bitcoin UTXO ของเขาควรใช้เพื่อผูกกับทรัพย์สิน RGB เหล่านี้

(Image source: Geekweb3/GeekWeb3)

1. Alice สร้างข้อมูลธุรกรรมสำหรับการโอนสินทรัพย์ RGB จาก Alice ไปยัง Bob พร้อมกับประวัติของสินทรัพย์เหล่านี้และนำมาให้ Bob ตรวจสอบ
2. หลังจากที่บ็อบยืนยันว่าข้อมูลถูกต้องท้องถิ่น เขาจึงส่งใบเสร็จถึงอลิซ เพื่อแจ้งให้เธอทราบว่าธุรกรรมสามารถดำเนินไปได้
3. Alice สร้างข้อมูลการโอน RGB "Alice to Bob" เข้าสู่ต้นไม้เมอร์เคิลและเผยแพร่รากเมอร์เคิลไปยังโซ่บิตคอยน์เป็นการสมัครสมาชิก เราสามารถเข้าใจการสมัครสมาชิกได้ง่ายๆ ว่าเป็นการหาค่าแฮชของข้อมูลการโอน
4. ถ้าในอนาคตมีคนต้องการยืนยันว่าการโอน "Alice to Bob" นั้นเกิดขึ้นจริง พวกเขาจำเป็นต้องทำสองอย่าง: ได้รับข้อมูลการโอนทั้งหมดของ "Alice to Bob" ภายใต้ Bitcoin chain และตรวจสอบว่า Commitment ที่สอดคล้อง (hash ของข้อมูลการโอน) มีอยู่บน Bitcoin chain

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

(Image source: BTCEden.org)

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

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

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

RGB++ นำเสนอการใช้วิธีการเก็บรักษาที่เต็มไปด้วยความหวัง โดยการแทนการตรวจสอบทางด้านลูกค้า

โปรโตคอลที่เรียกว่า RGB++ นำเสนอวิธีการใหม่โดยรวมโปรโตคอล RGB กับโซลด์เชนสนับสนุน UTXO เช่น CKB, Cardano, และ Fuel ระบบนี้ใช้เชือกตรวจสอบและเก็บข้อมูลสำหรับทรัพย์สิน RGB โดยการโอนงานตรวจสอบข้อมูลที่เคยทำโดยผู้ใช้ไปยังแพลตฟอร์ม/โซลด์บริการบุคคลที่สามเช่น CKB ซึ่งสามารถแทนที่การตรวจสอบที่ฝั่งลูกค้าด้วย "การตรวจสอบของแพลตฟอร์มบุคคลที่สาม" แค่เชื่อมั่นแพลตฟอร์ม/โซลด์เช่น CKB, Cardano, หรือ Fuel คุณสามารถดำเนินการต่อไปได้ หากคุณไม่เชื่อถือพวกเขา คุณสามารถสลับกลับไปใช้โหมด RGB แบบดั้งเดิมได้เสมอ

RGB++ และโปรโตคอล RGB เดิม理論上สามารถที่จะเข้ากันได้กัน; มันไม่ใช่เรื่องของอันหนึ่งหรืออีกอันแต่อย่างที่บอกมาพวกเขาสามารถใช้งานร่วมกันได้

เพื่อให้บรรลุผลดังกล่าวเราจําเป็นต้องใช้ประโยชน์จากแนวคิดที่เรียกว่า "homomorphic bindings" เครือข่ายสาธารณะเช่น CKB และ Cardano มีโมเดล UTXO แบบขยายของตัวเองซึ่งให้ความสามารถในการตั้งโปรแกรมได้มากกว่าเมื่อเทียบกับ UTXOs บนห่วงโซ่ Bitcoin "Homomorphic binding" เป็นแนวคิดของการใช้ UTXOs แบบขยายบนโซ่เช่น CKB, Cardano และ Fuel เป็น "คอนเทนเนอร์" สําหรับข้อมูลสินทรัพย์ RGB พารามิเตอร์ของสินทรัพย์ RGB ถูกเขียนลงในคอนเทนเนอร์เหล่านี้และแสดงโดยตรงบนบล็อกเชน เมื่อใดก็ตามที่ธุรกรรมสินทรัพย์ RGB เกิดขึ้นคอนเทนเนอร์สินทรัพย์ที่เกี่ยวข้องยังสามารถแสดงลักษณะที่คล้ายกันซึ่งคล้ายกับความสัมพันธ์ระหว่างเอนทิตีและเงา นี่คือสาระสําคัญของ "homomorphic binding"

(ภาพที่มา: RGB++ LightPaper)

ตัวอย่างเช่น หาก Alice เป็นเจ้าของ 100 RGB โทเค็นและ UTXO (เราเรียกว่า UTXO A) บนโซ่ Bitcoin และ UTXO บนโซ่ CKB ที่มีเครื่องหมาย "ยอดคงเหลือโทเค็น RGB: 100" และเงื่อนไขปลดล็อคที่เกี่ยวข้องกับ UTXO A:

ถ้า Alice ต้องการส่งทั้งหมด 30 โทเค็นให้กับ Bob เธอสามารถสร้างความมั่นใจก่อนด้วยคำบอกเล่าที่สอดคล้องกัน: โอน 30 โทเค็น RGB ที่เชื่อมโยงกับ UTXO A ไปยัง Bob และโอน 70 โทเค็นไปยัง UTXO อีกอันที่เธอควบคุมเอง

ต่อไป, Alice ใช้ UTXO A บน Bitcoin chain, เผยแพร่คำบรรยายด้านบน แล้วเริ่มต้นทำธุรกรรมบน CKB chain ธุรกรรมนี้เบี่ยงเบนคอนเทนเนอร์ UTXO ที่ถือ 100 RGB tokens โดยสร้างคอนเทนเนอร์สองใหม่: คนที่ถือ 30 tokens (สำหรับ Bob) และอีกคนที่ถือ 70 tokens (ที่ควบคุมโดย Alice) ระหว่างกระบวนการนี้ งานการตรวจสอบความถูกต้องของทรัพย์สินของ Alice และคำบรรยายของธุรกรรมจะเสร็จสมบูรณ์โดยการเชื่อมั่นร่วมกันของโหนดในเครือข่ายเช่น CKB หรือ Cardano โดยไม่มีการเกี่ยวข้องของ Bob ในจุดนี้ CKB และ Cardano ทำหน้าที่เป็นชั้นการตรวจสอบและชั้น DA (Data Availability) ตามลำดับ ภายใต้ Bitcoin chain

(ภาพที่มา: RGB++ LightPaper)

ข้อมูลสินทรัพย์ RGB ของบุคคลทั้งหมดจะถูกเก็บไว้ในห่วงโซ่ CKB หรือ Cardano ซึ่งเป็นลักษณะที่ตรวจสอบได้ทั่วโลกซึ่งอํานวยความสะดวกในการใช้งานสถานการณ์ DeFi เช่นกลุ่มสภาพคล่องและโปรโตคอลการปักหลักสินทรัพย์ แน่นอนว่าวิธีการข้างต้นยังเสียสละความเป็นส่วนตัว โดยพื้นฐานแล้วมันเกี่ยวข้องกับการแลกเปลี่ยนระหว่างความเป็นส่วนตัวและการใช้งานผลิตภัณฑ์ หากคุณให้ความสําคัญกับความปลอดภัยและความเป็นส่วนตัวสูงสุดคุณสามารถเปลี่ยนกลับไปใช้โหมด RGB แบบเดิมได้ หากคุณไม่สนใจการแลกเปลี่ยนเหล่านี้คุณสามารถใช้โหมด RGB ++ ได้อย่างมั่นใจขึ้นอยู่กับความต้องการส่วนบุคคลของคุณ (ในความเป็นจริงการใช้ประโยชน์จากฟังก์ชันการทํางานที่มีประสิทธิภาพของเครือข่ายสาธารณะเช่น CKB และ Cardano การทําธุรกรรมความเป็นส่วนตัวสามารถทําได้ผ่านการใช้ ZK)

สิ่งสำคัญที่ต้องการเน้นคือ RGB++ นำเสนอการสมมติที่สำคัญ: ผู้ใช้ต้องเชื่อมั่นอย่างโดดเดี่ยวว่า CKB/Cardano chain หรือเครือข่ายแพลตฟอร์มที่ประกอบด้วยจำนวนมากของโหนดผ่านโปรโตคอลเชิงประสงค์เป็นเชื่อถือได้และปลอดจากข้อผิดพลาด หากคุณไม่เชื่อถือ CKB คุณสามารถทำตามกระบวนการสื่อสารแบบโต้ตอบและการตรวจสอบในโปรโตคอล RGB เดิมโดยการเรียกใช้ไคลเอนต์ของคุณเอง

ในโปรโตคอล RGB++ ผู้ใช้สามารถใช้บัญชี Bitcoin ของตนเพื่อดำเนินการกับคอนเทนเนอร์สินทรัพย์ RGB บนเชน UTXO ของ CKB/Cardano โดยไม่จำเป็นต้องทำธุรกรรมที่เกี่ยวข้องกับต่างๆ พวกนี้คุณจำเป็นต้องใช้ลักษณะของ UTXOs ในเชนสาธารณะดังกล่าวและตั้งเงื่อนไขปลดล็อกของคอนเทนเนอร์เซลเพื่อเชื่อมโยงกับที่อยู่ Bitcoin/UTXO ที่เฉพาะเจาะจง หากฝ่ายที่เกี่ยวข้องในธุรกรรมสินทรัพย์ RGB มีความเชื่อในความปลอดภัยของ CKB พวกเขาอาจไม่จำเป็นต้องเผยแพร่ Commitments บ่อยครั้งบนเชน Bitcoin แทนที่พวกเขาสามารถรวมและส่ง Commitment ไปยังเชน Bitcoin หลังจากที่เกิดธุรกรรม RGB หลายรายการ ซึ่งเป็นส่วนหนึ่งของคุณลักษณะ "transaction folding" ซึ่งสามารถลดต้นทุนการทำธุรกรรมได้

สำคัญที่จะทราบว่า “containers” ที่ใช้ใน homomorphic bindings ต้องได้รับการสนับสนุนจาก public chains ที่ใช้โมเดล UTXO หรือมีคุณสมบัติที่คล้ายกันในโครงสร้างพื้นที่จัดเก็บสถานะของตน เชื่อมโยง EVM ไม่เหมาะสำหรับวัตถุประสงค์นี้และอาจพบเจออุปสรรคหลายประการ (หัวข้อนี้สามารถถูกพูดถึงในบทความที่แยกออกได้ เนื่องจากมีเนื้อหามากมาย ผู้อ่านที่สนใจสามารถอ้างอิงไปยังบทความก่อนหน้าจาก Geek Web3 ชื่อ “RGB++ และการผูก Homomorphic: วิธี CKB, Cardano, และ Fuel ให้พลังให้กับระบบ Bitcoin“)

สรุปมา สายงานสาธารณะหรือชั้นฟังก์ชันส่วนขยายที่เหมาะสำหรับการนำมาใช้ในการทำให้เข้าข่ายเพียงอย่างเดียวควรมีลักษณะดังต่อไปนี้:

1. ใช้โมเดล UTXO หรือระบบจัดเก็บสถานะที่คล้ายกัน
2. ให้ความสามารถในการโปรแกรม UTXO ที่เพียงพอ ทำให้นักพัฒนาสามารถเขียนสคริปต์ปลดล็อกได้
3. มีพื้นที่สถานะที่เกี่ยวข้องกับ UTXOs ที่สามารถเก็บสถานะของสินทรัพย์ได้
4. มีสะพานหรือโหนดที่เกี่ยวข้องกับ Bitcoin หรือโหนดเบาที่ใช้ได้

คำปฏิเสธ：

1. This article is reprinted from [极客 Web3], All copyrights belong to the original author [Faust]. If there are objections to this reprint, please contact the Gate เรียนทีม และพวกเขาจะดำเนินการโดยเร็ว
2. คำปฏิเสธความรับผิด: มุมมองและความคิดเห็นที่แสดงในบทความนี้เป็นเพียงเพียงของผู้เขียนเท่านั้น และไม่ใช่เป็นคำแนะนำในการลงทุนใดๆ
3. การแปลบทความเป็นภาษาอื่น ๆ ทำโดยทีม Gate Learn นอกจากที่กล่าวถึงไว้เป็นอย่างอื่น การคัดลอก การกระจาย หรือการลอกเลียนบทความที่ถูกแปลนั้นถูกห้าม