ผู้เขียนต้นฉบับ: Faust, Geek web3 BTCEden.org Lianchuang (X: @faustliu1997)

แหล่งที่มาดั้งเดิม:กีคเว็บ3

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

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

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

โปรโตคอล RGB: ผู้ใช้ต้องทำการตรวจสอบข้อมูลด้วยตนเอง

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

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

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

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

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

(แหล่งรูปภาพ: Coinex)

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

นี่คือบทสรุปขั้นตอนการทำงานของโปรโตคอล RGB:

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

(แหล่งรูปภาพ: Geek web3/ Geek Web3)

• Alice สร้างข้อมูลการโอนเนื้อหา RGB Alice to Bob พร้อมด้วยแหล่งที่มาในอดีตของเนื้อหาเหล่านี้ และมอบให้ Bob เพื่อตรวจสอบ

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

• Alice สร้างข้อมูลการถ่ายโอน RGB ของ Alice to Bob ลงใน Merkle Tree และเผยแพร่ Merkle Root ไปยัง Bitcoin chain เป็น Commitment เราสามารถเข้าใจ Commitment ว่าเป็นแฮชของข้อมูลการถ่ายโอน

• หากมีใครต้องการยืนยันในอนาคตว่าการโอน Alice to Bob ที่กล่าวข้างต้นเกิดขึ้นจริง เขาต้องทำสองสิ่ง: รับข้อมูลการโอน Alice to Bob ที่สมบูรณ์ภายใต้ห่วงโซ่ Bitcoin จากนั้นตรวจสอบว่า มีธุรกรรมที่สอดคล้องกันในความมุ่งมั่นของห่วงโซ่ Bitcoin (แฮชของการถ่ายโอนข้อมูล) แค่นั้นแหละ.

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

(แหล่งรูปภาพ: BTCEden.org)

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

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

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

RGB++: การตรวจสอบไคลเอ็นต์กลายเป็นการโฮสต์ในแง่ดี

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

RGB++ และโปรโตคอล RGB ดั้งเดิมนั้นเข้ากันได้ในทางทฤษฎี

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

(แหล่งรูปภาพ: RGB++ LightPaper)

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

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

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

(แหล่งรูปภาพ: RGB++ LightPaper)

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

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

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

อย่างไรก็ตาม ควรสังเกตว่า คอนเทนเนอร์ ที่ใช้ในการรวม isomorphic ต้องการเชนสาธารณะที่รองรับโมเดล UTXO หรือโครงสร้างพื้นฐานที่มีลักษณะคล้ายกันในที่เก็บข้อมูลสถานะ เชน EVM ไม่เหมาะสมและจะพบกับข้อผิดพลาดมากมาย (หัวข้อนี้สามารถเขียนแยกกันได้และเกี่ยวข้องกับเนื้อหาจำนวนมาก ผู้อ่านที่สนใจสามารถดูบทความก่อนหน้าของ Geek Web3การเชื่อมโยง RGB++ และ Isomorphic: CKB, Cardano และเชื้อเพลิงเสริมพลังให้กับระบบนิเวศ Bitcoin อย่างไร；

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

• ใช้โมเดล UTXO หรือรูปแบบหน่วยเก็บข้อมูลสถานะที่คล้ายกัน

• มีความสามารถในการโปรแกรม UTXO อย่างมาก ทำให้นักพัฒนาสามารถเขียนสคริปต์ปลดล็อคได้

• มีพื้นที่สถานะที่เกี่ยวข้องกับ UTXO ที่สามารถจัดเก็บสถานะสินทรัพย์ได้

• มีสะพานหรือโหนดที่เกี่ยวข้องกับ Bitcoin