ส่งต่อชื่อเรื่องต้นฉบับ 'RGB++ และการผูกพันเชิงสมมติ: CKB, Cardano และ Fuel ว่าทำอย่างไรเพื่อเสริมพลังนิเวศของ Bitcoin กับ

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

· ในโปรโตคอล RGB ++ ผู้ใช้ไม่จําเป็นต้องเรียกใช้ไคลเอนต์เพื่อตรวจสอบข้อมูลธุรกรรมเป็นการส่วนตัวและสามารถส่งมอบงานต่างๆเช่นการตรวจสอบความถูกต้องของสินทรัพย์และการจัดเก็บข้อมูลไปยังห่วงโซ่ UTXO เช่น CKB และ Cardanao.As ตราบใดที่คุณ "มองโลกในแง่ดี" และเชื่อว่าความปลอดภัยของเครือข่ายสาธารณะข้างต้นค่อนข้างน่าเชื่อถือ ไม่จําเป็นต้องตรวจสอบด้วยตัวเอง

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

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

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

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

3. มีพื้นที่สถานะที่เกี่ยวข้องกับ UTXO ที่สามารถเก็บสถานะสินทรัพย์;

4. มันสามารถสนับสนุนการทำงานของโหนดแสงบิทคอยน์ผ่านสมาร์ทคอนแทรคหรือวิธีอื่น ๆ;

· นอกจาก CKB แล้ว Cardano และ Fuel ยังสามารถรองรับการผูกไอโซมอร์ฟิกได้อีกด้วย อย่างไรก็ตามสองหลังอาจมีสัมภาระในแง่ของภาษาสัญญาอัจฉริยะและรายละเอียดการออกแบบสัญญา ในปัจจุบันดูเหมือนว่า CKB จะเหมาะสมกว่าสองหลังเป็นเลเยอร์การขยายฟังก์ชันสําหรับโปรโตคอลสินทรัพย์ Bitcoin ที่มีขอบเขตแบบ isomorphically

ในปีพ.ศ. 2560 ไซเฟอร์ โค้ชใหญ่ของ Nervos CKB ได้เสนอแนวคิดผลิตภัณฑ์ครั้งแรกเกี่ยวกับการผูกอิซอโมร์ฟิก โดยเปรียบเทียบกับแนวทาง Layer 2 ของ Bitcoin อื่น ๆ การผูกอิซอโมร์ฟิกสามารถทำให้เข้ากันได้ดีกว่ากับโปรโตคอลสินทรัพย์อื่น ๆ เช่น RGB, Runes, และ Atomical และสามารถหลีกเลี่ยงปัจจัยต่าง ๆ เช่นสินทรัพย์ที่เชื่อมโยงกันที่นำมาภาระภัยเพิ่มเติม

พูดง่ายๆ ก็คือ การผูกไอโซมอร์ฟิกใช้ UTXO บนโซ่ CKB และ Cardano เป็น "คอนเทนเนอร์" เพื่อแสดงสินทรัพย์ UTXO เช่น RGB ซึ่งจะเป็นการเพิ่มความสามารถในการตั้งโปรแกรมและสถานการณ์ที่ซับซ้อนมากขึ้น ก่อนหน้านี้ Geek web3 ได้ปรากฏตัวใน "จากบิทคอยน์ไปยัง Sui, ADA และ Nervos: โมเดล UTXO และส่วนขยายที่เกี่ยวข้องหลังจากที่รวบรวมบล็อกเชนซีรีส์ที่รองรับ UTXO โปรแกรมได้เรียบร้อยแล้ว บทความนี้จะไปสำรวจเพิ่มเติมว่าบล็อกเชนเหล่านี้สามารถปรับตัวให้เข้ากับโครงสร้างการผูกอีโซโมร์ฟิกได้หรือไม่

RGB++ และการผูกอิซอโมร์ฟิก

ก่อนที่จะวิเคราะห์ความเข้ากันได้ของเชื่อมโยง UTXO chains ที่แตกต่างกันด้วยการเชื่อมโยงอิซโมร์ฟิก เราต้องแนะนำหลักการของการเชื่อมโยงอิซโมร์ฟิกก่อน การเชื่อมโยงอิซโมร์ฟิกเป็นคอนเซ็ปท์ที่ถูกโน้มน้าวโดยทีม CKB ในพร็อตโตคอล RGB++ ดังนั้นที่นี่เราใช้ขั้นตอนการทำงานของ RGB++ เพื่อแนะนำว่าการเชื่อมโยงอิซโมร์ฟิกที่ใช้เป็นของ CKB คืออะไร

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

โปรโตคอลสินทรัพย์เช่นโปรโตคอล RGB และ ERC-20 ทํางานในรูปแบบที่แตกต่างกันมาก สัญญา ERC-20 บน Ethereum บันทึกสถานะสินทรัพย์ของผู้ใช้ทั้งหมด และไคลเอนต์โหนด Ethereum จะซิงโครไนซ์และตรวจสอบข้อมูลการถ่ายโอนทั้งหมด และบันทึกการอัปเดตสถานะหลังจากการโอนในสัญญาสินทรัพย์ สิ่งนี้เป็นที่รู้จักของผู้คนมาเป็นเวลานานและไม่มีอะไรมากไปกว่าการพึ่งพากระบวนการฉันทามติของ Ethereum เพื่อให้แน่ใจว่าการเปลี่ยนแปลงสถานะของสินทรัพย์เป็นไปอย่างราบรื่น เนื่องจากฉันทามติของโหนด Ethereum มีความน่าเชื่อถือมากผู้ใช้จึงสามารถเริ่มต้นแพลตฟอร์มการดูแลสินทรัพย์ตามสัญญา ERC-20 ว่า "ไม่มีปัญหา" แม้ว่าพวกเขาจะไม่ได้เรียกใช้ไคลเอนต์ก็ตาม

แต่โปรโตคอล RGB นั้นแปลกมาก เพื่อเพิ่มความเป็นส่วนตัวเพียงแค่ลบฉันทามติของโหนด / ไคลเอนต์ซึ่งเป็นสิ่งธรรมดาในโลกบล็อกเชน ผู้ใช้ต้องเรียกใช้ไคลเอนต์ RGB ด้วยตนเองและรับและจัดเก็บ "ข้อมูลสินทรัพย์ที่เกี่ยวข้องกับตัวเอง" เท่านั้น พวกเขามองไม่เห็นสิ่งที่คนอื่นทํา ซึ่งแตกต่างจาก Ethereum และ ERC-20 มีบันทึกการถ่ายโอนที่มองเห็นได้ทั้งหมดในห่วงโซ่

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

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

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

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

(แผนภูมิการโต้ตอบโปรโตคอล RGB)

เนื่องจากไม่มีความเห็นร่วมกันในหมวด RGB clients, การปล่อย RGB asset contract ไม่สามารถกระจายไปยังโหนดทั้งหมดได้ “อย่างเชื่อถือได้อย่างมาก” ผู้เผยแพร่สัญญาและผู้ใช้เรียนรู้ข้อมูลของ RGB asset contract โดยสุ่มเฉยๆ ผ่านทางอีเมลหรือทวิตเตอร์ และรูปแบบเป็นอย่างไม่เป็นทางการ

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

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

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

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

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

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

เกี่ยวกับปัญหาที่กล่าวถึงข้างต้น, โซลูชันของ RGB++ คือ อนุญาตให้ผู้ใช้สลับระหว่างโหมดการตรวจสอบด้วยตนเองของไคลเอนต์และโหมดการโฮสต์โดยบุคคลที่สาม ผู้ใช้สามารถปล่อยภาระการตรวจสอบข้อมูลและการเก็บรักษา, การโฮสต์สมาร์ทคอนแทรค, ฯลฯ ให้กับ CKB แน่นอน, ผู้ใช้ต้องเชื่อมั่นและเชื่อใจว่า CKB โซลูชันเครือข่ายสาธารณะ POW เป็นที่เชื่อถือได้; หากบางคนมีความตายตัวสูงและความเป็นส่วนตัว, เช่น นักลงทุนใหญ่ที่มีสินทรัพย์มาก ก็สามารถย้อนกลับไปยังโหมด RGB เดิม สิ่งที่ควรเน้นที่นี่คือ RGB++ และโปรโตคอล RGB เดิมทฤษฎี上 สามารถทำงานร่วมกันได้

(แผนภูมิการไหลของการโต้ตอบโปรโตคอล RGB ++ [เวอร์ชันสั้น])

ในบทความก่อนหน้า“จาก RGB สู่ RGB++: วิธี CKB ทำให้โปรโตคอลสินทรัพย์ทางนิเวศ Bitcoin มีพลัง”, เราได้ทำให้ "การผูกอิซโมร์ฟิก" ของ RGB++ เป็นที่นิยมสั้น ๆ ไปแล้ว ตอนนี้เราจะทบทวนอย่างรวดเร็ว:

CKB มี UTXO แบบขยายของตัวเองที่เรียกว่า Cell ซึ่งสามารถตั้งโปรแกรมได้มากกว่า UTXO ในห่วงโซ่ BTC "isomorphic binding" คือการใช้เซลล์บนห่วงโซ่ CKB เป็น "คอนเทนเนอร์" สําหรับข้อมูลสินทรัพย์ RGB และเขียนพารามิเตอร์หลักของสินทรัพย์ RGB ลงในเซลล์

เนื่องจากมีความสัมพันธ์ที่มีผลผูกพันระหว่างสินทรัพย์ RGB และ Bitcoin UTXO รูปแบบตรรกะของสินทรัพย์จึงมีลักษณะของ UTXO andCell ซึ่งมีลักษณะ UTXO นั้นเหมาะอย่างยิ่งในฐานะ "คอนเทนเนอร์" สําหรับสินทรัพย์ RGB เมื่อใดก็ตามที่ธุรกรรมสินทรัพย์ RGB เกิดขึ้นคอนเทนเนอร์เซลล์ที่เกี่ยวข้องยังสามารถแสดงลักษณะที่คล้ายกันเช่นเดียวกับความสัมพันธ์ระหว่างเอนทิตีและเงา นี่คือสาระสําคัญของ "isomorphic binding"

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

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

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

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

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

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

พูดง่ายๆก็คือ Isomorphic binding ไม่เพียง แต่ใช้กับ RGB เท่านั้น แต่ยังรวมถึงโปรโตคอลสินทรัพย์ต่างๆที่มีคุณสมบัติ UTXO เช่น Runes และ Atomic ซึ่งจะถ่ายโอนสถานะสินทรัพย์ข้อมูลในอดีตและสัญญาอัจฉริยะที่เกี่ยวข้องทั้งหมดที่จัดเก็บไว้ในไคลเอนต์ผู้ใช้ไปยังเครือข่ายสาธารณะ UTXO เช่น CKB หรือ Cardano สําหรับการจัดเก็บและการโฮสต์ โปรโตคอลสินทรัพย์ UTXO ที่กล่าวถึงข้างต้นสามารถใช้โมเดล UTXO ของ CKB หรือ Cardano เป็น "คอนเทนเนอร์" เพื่อแสดงรูปร่างและสถานะของสินทรัพย์ สะดวกในการร่วมมือกับสถานการณ์ต่างๆเช่นสัญญาอัจฉริยะ

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

หากทั้งสองฝ่ายที่เกี่ยวข้องกับธุรกรรมสินทรัพย์ RGB สามารถไว้วางใจความปลอดภัยของ CKB พวกเขาไม่จําเป็นต้องออกข้อผูกพันบ่อยครั้งในห่วงโซ่ Bitcoin หลังจากทําการโอน RGB หลายครั้งแล้วสามารถส่งคํามั่นสัญญาไปยังห่วงโซ่ Bitcoin ได้ สิ่งนี้เรียกว่าฟังก์ชัน "การพับธุรกรรม" สามารถลดต้นทุนการใช้งาน

อย่างไรก็ตามควรสังเกตว่า "คอนเทนเนอร์" ที่ใช้ในการผูกไอโซมอร์ฟิกมักต้องใช้โซ่สาธารณะที่รองรับโมเดล UTXO หรืออินฟาเรดที่มีลักษณะคล้ายกันในการจัดเก็บของรัฐและเห็นได้ชัดว่าโซ่ EVM ไม่เหมาะสมและจะมีปัญหาการใช้งานทางเทคนิค พบข้อผิดพลาดมากมาย ประการแรกดังที่ได้กล่าวไว้ก่อนหน้านี้ RGB ++ "สามารถใช้งานคอนเทนเนอร์สินทรัพย์บนห่วงโซ่ CKB โดยไม่มี cross-chain" ซึ่งโดยพื้นฐานแล้วเป็นไปไม่ได้ที่จะนําไปใช้กับห่วงโซ่ EVM แม้ว่าจะถูกบังคับให้ดําเนินการ แต่ค่าใช้จ่ายอาจสูงมาก

นอกจากนี้ในโปรโตคอล RGB ++ หลายคนไม่จําเป็นต้องเรียกใช้ไคลเอนต์หรือจัดเก็บข้อมูลสินทรัพย์ไว้ในเครื่อง หากใช้วิธี ERC-20 เพื่อบันทึกยอดคงเหลือของสินทรัพย์ของทุกคนในสัญญานี้หากมีคนต้องการถอยกลับไปสู่โหมดการตรวจสอบตนเองของลูกค้าและเสนอให้ตรวจสอบแหล่งที่มาของสินทรัพย์ของใครบางคนในเวลานี้เขาอาจต้องสแกนบันทึกการทําธุรกรรมทั้งหมดที่โต้ตอบกับสัญญาสินทรัพย์จะนํามาซึ่งแรงกดดันอย่างมาก

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

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

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

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

ปัจจุบันสคริปต์การล็อค UTXO บน CKB สามารถตั้งโปรแกรมได้และเจ้าหน้าที่ยังเข้ากันได้กับรูปแบบลายเซ็นของเครือข่ายสาธารณะที่แตกต่างกัน สําหรับการผูก isomorphic เครือข่าย CKB โดยทั่วไปจะตรงตามลักษณะข้างต้น แล้วเครือข่ายสาธารณะที่ใช้ UTXO อื่น ๆ ล่ะ? เราได้ดําเนินการตรวจสอบเบื้องต้นของเชื้อเพลิงและ Cardano และเชื่อว่าพวกเขาสามารถสนับสนุนในทางทฤษฎีการผูก isomorphic

เชื้อเพลิง: Ethereum OP Rollup ที่มีพื้นฐานบน UTXO

Fuel เป็น Ethereum OP Rollup ที่ใช้เป็นรากฐานบน UTXO และเป็นผู้นำในการนำเสนอแนวคิดของการพิสูจน์การทุจริตเข้าสู่ระบบนอ 2 ของ Ethereum โดยสำคัญ สำหรับการสนับสนุนฟังก์ชัน UTXO ปกติ Fuel เป็นสม่ำเสมอกับ BTC

Fuel แบ่ง UTXO ภายในเป็น 3 ประเภท คือ

เหรียญนำเข้า: Standard UTXO, ใช้เพื่อแทนสินทรัพย์ของผู้ใช้, มีการล็อกเวลาแบบธรรมชาติ, และอนุญาตให้ผู้ใช้เขียนสคริปต์ปลดล็อก;

Input Contract: UTXO ที่ใช้สำหรับการเรียกสัญญาประกอบด้วยข้อมูล เช่น state root ของสัญญาและสินทรัพย์ของสัญญา;

ข้อความนำเข้า: UTXO ที่ใช้สำหรับส่งข้อมูลส่วนใหญ่ประกอบด้วยฟิลด์เช่นผู้รับข้อมูล;

เมื่อผู้ใช้ใช้จ่าย UTXO ผลลัพธ์ที่ได้คือ

เหรียญเขาออก: สำหรับการโอนสินทรัพย์มาตรฐาน;

ผลลัพธ์ของสัญญา : ผลลัพธ์ที่สร้างขึ้นโดยการกระทำกับสัญญาภายในมีรากสถานะหลังการกระทำกับสัญญา;

สร้างสัญญาเอาท์พุต: UTXO พิเศษคือเอาท์พุตที่สร้างขึ้นเมื่อสร้างสัญญา ซึ่งประกอบด้วย ID และรากสถานะของสัญญา;

ในขณะที่ Cell ของ CKB มีสถานะสัญญาทั้งหมดภายใน แต่ UTXO ของ Fuel จริงๆ แล้วไม่สามารถพกสถานะสัญญาทั้งหมดที่เกี่ยวข้องกับธุรกรรม Fuel จะพกเพียงรากสถานะของสัญญา Stateroot ใน UTXO ซึ่งเป็นรากของต้นไม้สถานะ สถานะทั้งหมดของสัญญาจะถูกเก็บไว้ในห้องสมุดสถานะของ Fuel และเป็นเจ้าของโดยสัญญาฉลากอัจฉริยะ

ควรกล่าวถึงว่าเกี่ยวกับการประมวลผลสถานะของสมาร์ทคอนแทร็ค สัญญาเชื้อเพลิงและสัญญาความแข็งแรงมีความเห็นในแง่รูปแบบโปรแกรมที่เข้าใจและใกล้ชิดกัน ภาพด้านล่างแสดงสัญญาตัวนับที่เขียนด้วยภาษา Sway ของ Fuel สัญญาประกอบด้วยตัวนับ เมื่อผู้ใช้เรียกใช้ฟังก์ชัน increment_counter ตัวนับที่เก็บอยู่ในสัญญาจะเพิ่มขึ้น 1

เราสามารถเห็นว่าตรรกะการเขียนของสัญญา Sway คล้ายกับของสัญญา Solidity ทั่วไป โดยเราจะให้ ABI ของสัญญาก่อน จากนั้นคือตัวแปรสถานะของสัญญา และหลังจากนั้นคือการดำเนินการเฉพาะของสัญญา กระบวนการเขียนโค้ดทั้งหมดไม่เกี่ยวข้องกับระบบ UTXO ของ Fuel

ดังนั้น ประสบการณ์ในการเขียนโปรแกรมของ Fuel แตกต่างจากภาษาโปรแกรม UTXO เช่น CKB และ Cardano Fuel มีประสบการณ์ใกับการเขียนโปรแกรมและการพัฒนาสมาร์ทคอนแทรค EVM ใกล้เคียงกว่า นักพัฒนายังสามารถใช้ภาษา Sway ในการสร้างสคริปต์การปลดล็อคเพื่อดำเนินตรวจสอบวิธีเป็นลายเซ็นเจอร์พิเศษหรือตรรกะการปลดล็อคหลายลายเซ็นเจอร์

มันเป็นเรื่องที่เป็นไปได้ในพื้นฐานที่จะนำมาใช้ในการผูกอีซูโมอร์ฟิกใน Fuel แต่ยังมีปัญหาต่อไปนี้:

ภาษาที่ใช้โดย Fuel เข้าใกล้กับโซ่ EVM ในด้านการออกแบบสมาร์ทคอนแทร็คมากกว่า BTC หรือ CKB และ Cardano ผู้ออกใช้สินทรัพย์ UTXO เช่น RGB และ Atomics ต้องสร้างสัญญาสมาร์ทบน Fuel โดยเฉพาะ CKB และโซ่อื่น ๆ ใช้อีกอันหนึ่งซึ่งซับซ้อนมาก

Cardano: โซนสาธารณะ eUTXO ที่มีพื้นฐานบน POS

Cardano เป็นบล็อกเชนอีกตัวที่ใช้โมเดล UTXO แต่ไม่เหมือน Fuel มันเป็นเครือข่ายสาธารณะชั้น 1 Cardano ใช้ eUTXO (extended UTXO) เพื่ออ้างถึงโมเดลโปรแกรม UTXO ในระบบของมัน ต่างจาก CKB eUTXO ใน Cardano ประกอบด้วยโครงสร้างต่อไปนี้:

สคริปต์: สมาร์ทคอนแทรคถูกใช้เพื่อยืนยันว่า UTXO สามารถถูกปลดล็อคและดำเนินการเปลี่ยนแปลงสถานะ;

Redeemers: ข้อมูลที่ผู้ใช้提供สำหรับการปลดล็อค UTXO พื้นที่ข้อมูลลายเซ็นเนเจอร์ที่เป็นทั่วไป ที่คล้ายกับ Witness ของ Bitcoin;

ข้อมูล: พื้นที่สถานะของสมาร์ทคอนแทรคส์สามารถเก็บข้อมูล เช่น สถานะสินทรัพย์;

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

นักพัฒนาสามารถใช้ภาษา PlutusCore เพื่อเขียนโปรแกรม UTXO บนโซ่ Cardano โดยคล้ายกับ CKB นักพัฒนาสามารถเขียนสคริปต์การปลดล็อกและฟังก์ชันบางอย่างสำหรับการอัปเดตสถานะ

เราจะแนะนำโมเดลโปรแกรมมิ่ง UTXO ของ Cardano พร้อมกับกระบวนการประมูลที่ใช้ระบบ UTXO สมมติว่าเราต้องการนำเข้า DAPP การประมูลสินทรัพย์ที่ต้องการผู้ใช้ให้ประมูลก่อนที่การประมูลจะจบ โดยเฉพาะผู้ใช้จะบริโภค UTXO ของตนเอง, ทำสัญญา UTXO กับการประมูลนี้, และจากนั้นสร้าง UTXO ใหม่ เมื่อมีคนใดให้ราคาประมูลสูงขึ้น, นอกจากการสร้าง UTXO สัญญาประมูลใหม่, ยังจะมีการสร้าง UTXO การคืนเงินสำหรับคนก่อนหน้าด้วย กระบวนการเฉพาะคือดังนี้:

เพื่อให้สามารถดำเนินการกระบวนการประมูลดังกล่าวได้ บางส่วนต้องถูกเก็บไว้ใน UTXO ของสัญญาฉลากประมูลอัจฉริยะ เช่น ราคาสูงสุดของการประมูลปัจจุบันและบุคคลที่ทำการประมูล ภาพด้านล่างแสดงคำกล่าวเกี่ยวกับสถานะภายใน PlutusCore เราสามารถเห็นได้ว่า bBidder และ bAmount แสดงการประมูลและที่อยู่ของกระเป๋าที่ทำการประมูล พารามิเตอร์การประมูลมีข้อมูลพื้นฐานของการประมูล

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

เป็นไปได้ที่จะสร้างการผูก isomorphic บน Cardano เราสามารถใช้ Datum เพื่อจัดเก็บสถานะสินทรัพย์และเขียนสคริปต์เฉพาะเพื่อให้เข้ากันได้กับอัลกอริทึมลายเซ็นที่เกี่ยวข้องกับ Bitcoin แต่ปัญหาร้ายแรงคือโปรแกรมเมอร์ส่วนใหญ่อาจไม่สามารถปรับตัวเข้ากับการใช้ PlutusCore สําหรับการเขียนโปรแกรมตามสัญญาได้ ยิ่งไปกว่านั้นสภาพแวดล้อมการเขียนโปรแกรมนั้นตั้งค่าได้ยากและไม่เป็นมิตรกับนักพัฒนา

สรุป

การผูกไอโซมอร์ฟิกต้องการให้โซ่มีคุณสมบัติดังต่อไปนี้:

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

เนื่องจากความพิเศษของแนวคิดการเขียนโปรแกรมสัญญาอัจฉริยะ Fuel จึงเข้ากันได้กับการผูกไอโซมอร์ฟิก แต่ก็ยังนําสัมภาระมาด้วย ในขณะที่ Cardaon ใช้ภาษาการเขียนโปรแกรม Haskell สําหรับการเขียนโปรแกรมตามสัญญาซึ่งทําให้นักพัฒนาส่วนใหญ่เริ่มต้นได้อย่างรวดเร็ว จากเหตุผลข้างต้น CKB ซึ่งใช้ชุดคําสั่ง RISC-V และมีความสมดุลมากขึ้นในลักษณะของการเขียนโปรแกรม UTXO อาจเป็นเลเยอร์การขยายฟังก์ชันที่เหมาะสมกว่าสําหรับการผูกไอโซมอร์ฟิก

ข้อความประกัน

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