การประลองสัญญาอัจฉริยะ: Hyperledger Fabric vs MultiChain vs Ethereum vs Corda

มีหลายวิธีในการใส่รหัสบน blockchain

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

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

ในบทความนี้ เป้าหมายของฉันคือการตรวจสอบความแตกต่างที่สำคัญระหว่างแนวทางสัญญาอัจฉริยะและการแลกเปลี่ยนที่เป็นตัวแทน ฉันจะทำสิ่งนี้โดยดูจากสี่แพลตฟอร์มบล็อกเชนระดับองค์กรยอดนิยม ซึ่งรองรับโค้ดบนเชนที่กำหนดเองบางรูปแบบ ประการแรก IBM's ผ้า Hyperledgerซึ่งเรียกสัญญาว่า "รหัสลูกโซ่" ประการที่สอง แพลตฟอร์ม MultiChain ของเราซึ่งแนะนำ ตัวกรองอัจฉริยะ ในเวอร์ชัน 2.0 ที่สาม, Ethereum (และได้รับอนุญาต องค์ประชุม และ โพรง แยกส่วน) ซึ่งเป็นที่นิยมในชื่อ "สัญญาอัจฉริยะ" และในที่สุดก็, R3 Cordaซึ่งอ้างอิงถึง “สัญญา” ในการทำธุรกรรม แม้จะมีคำศัพท์ที่แตกต่างกันทั้งหมด แต่ท้ายที่สุดแล้วทั้งหมดเหล่านี้อ้างถึงสิ่งเดียวกัน นั่นคือรหัสเฉพาะแอปพลิเคชันที่กำหนดกฎของลูกโซ่

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

พื้นฐานของบล็อคเชน

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

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

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

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

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

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

มาเริ่มกันที่กฎการทำธุรกรรม ความท้าทายแรกเหล่านี้ และดูว่าพวกเขาแสดงออกอย่างไรใน Fabric, MultiChain, Ethereum และ Corda ตามลำดับ

กฎการทำธุรกรรม

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

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

อินพุตและเอาต์พุต

แพลตฟอร์มบล็อกเชนของเราใช้แนวทางกว้างๆ สองวิธีในการแสดงกฎการทำธุรกรรม อย่างแรกซึ่งฉันเรียกว่า "โมเดลอินพุต-เอาต์พุต" ใช้ใน MultiChain และ Corda ในที่นี้ ธุรกรรมจะแสดงรายการแถวฐานข้อมูลหรือ “สถานะ” อย่างชัดเจนที่พวกเขาลบและสร้าง โดยสร้างชุดของ “อินพุต” และ “เอาต์พุต” ตามลำดับ การแก้ไขแถวจะแสดงเป็นการดำเนินการที่เทียบเท่ากับการลบแถวนั้นและสร้างแถวใหม่แทน

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

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

ควรสังเกตว่า แม้จะแชร์โมเดลอินพุต-เอาต์พุต MultiChain และ Corda ใช้งานมันแตกต่างกันมาก ใน MultiChain เอาต์พุตสามารถมีเนื้อหาและ/หรือข้อมูลในรูปแบบ JSON ข้อความหรือไบนารี กฎถูกกำหนดไว้ใน "ตัวกรองธุรกรรม" หรือ "ตัวกรองสตรีม" ซึ่งสามารถตั้งค่าให้ตรวจสอบธุรกรรมทั้งหมด หรือเฉพาะที่เกี่ยวข้องกับสินทรัพย์หรือการจัดกลุ่มข้อมูลเฉพาะ ในทางตรงกันข้าม "สถานะ" ของเอาต์พุต Corda จะแสดงโดยอ็อบเจ็กต์ในภาษาการเขียนโปรแกรม Java หรือ Kotlin พร้อมฟิลด์ข้อมูลที่กำหนดไว้ กฎของคอร์ดากำหนดไว้ใน "สัญญา" ซึ่งผูกติดอยู่กับบางรัฐ และสัญญาของรัฐจะใช้เฉพาะกับธุรกรรมที่มีสถานะนั้นในข้อมูลเข้าหรือออก สิ่งนี้เกี่ยวข้องกับ Corda's แบบจำลองการมองเห็นที่ผิดปกติซึ่งการทำธุรกรรมสามารถมองเห็นได้โดยคู่สัญญาของพวกเขาหรือผู้ที่การทำธุรกรรมในภายหลังที่พวกเขาได้รับผลกระทบ

สัญญาและข้อความ

วิธีที่สอง ซึ่งฉันเรียกว่า "รูปแบบข้อความสัญญา" ใช้ใน Hyperledger Fabric และ Ethereum ที่นี่ สามารถสร้าง “สัญญาอัจฉริยะ” หรือ “รหัสลูกโซ่” ได้หลายรายการบนบล็อคเชน และแต่ละรายการมีฐานข้อมูลและรหัสที่เกี่ยวข้องกัน ฐานข้อมูลของสัญญาสามารถแก้ไขได้ด้วยรหัสเท่านั้น แทนที่จะแก้ไขโดยธุรกรรมบล็อคเชนโดยตรง รูปแบบการออกแบบนี้คล้ายกับ "การห่อหุ้ม" ของโค้ดและข้อมูลในการเขียนโปรแกรมเชิงวัตถุ

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

ทั้ง Fabric และ Quorum ซึ่งเป็นรูปแบบหนึ่งของ Ethereum ทำให้ภาพนี้ซับซ้อนโดยอนุญาตให้เครือข่ายกำหนด “ช่องสัญญาณ” หรือ “สถานะส่วนตัว” ได้หลายแบบ จุดมุ่งหมายคือเพื่อบรรเทาปัญหาการรักษาความลับของบล็อคเชนโดยการสร้างสภาพแวดล้อมที่แยกจากกัน ซึ่งแต่ละแห่งสามารถมองเห็นได้เฉพาะกลุ่มย่อยของผู้เข้าร่วมเท่านั้น แม้ว่าสิ่งนี้จะฟังดูมีแนวโน้มในทางทฤษฎี แต่ในความเป็นจริงแล้ว สัญญาและข้อมูลในแต่ละช่องทางหรือรัฐเอกชนนั้นแยกออกจากสัญญาอื่นๆ ด้วยเหตุนี้ ในแง่ของสัญญาอัจฉริยะ สภาพแวดล้อมเหล่านี้จึงเทียบเท่ากับบล็อกเชนที่แยกจากกัน

กฎตัวอย่าง

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

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

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

ในรูปแบบข้อความสัญญา สัญญาของสินทรัพย์รองรับข้อความ "ส่งการชำระเงิน" ซึ่งใช้พารามิเตอร์สามตัว ได้แก่ ที่อยู่ผู้ส่ง ที่อยู่ผู้รับ และปริมาณที่จะส่ง ในการตอบสนองสัญญาดำเนินการสี่ขั้นตอนต่อไปนี้:

1. ตรวจสอบว่าธุรกรรมถูกลงนามโดยผู้ส่ง
2. ตรวจสอบว่าผู้ส่งมีเงินเพียงพอ
3. หักจำนวนที่ร้องขอจากแถวของผู้ส่ง
4. เพิ่มปริมาณนั้นในแถวของผู้รับ

หากการตรวจสอบอย่างใดอย่างหนึ่งในสองขั้นตอนแรกล้มเหลว สัญญาจะถูกยกเลิกและจะไม่มีการชำระเงินใด ๆ

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

อยู่นอกเหนือขอบเขตของเราที่นี่เพื่อสำรวจว่าคำตอบควรมีอิทธิพลต่อทางเลือกระหว่างสองโมเดลนี้อย่างไร แต่ตามแนวทางทั่วไป ในการพัฒนาแอปพลิเคชันบล็อกเชนใหม่ คุณควรพยายามแสดงกฎการทำธุรกรรมในทั้งสองรูปแบบ และพิจารณาว่าสิ่งใดเหมาะสมกว่ากัน ความแตกต่างจะแสดงออกมาในแง่ของ: (a) ความง่ายในการเขียนโปรแกรม (b) ข้อกำหนดการจัดเก็บและปริมาณงาน และ (c) ความเร็วของการตรวจจับข้อขัดแย้ง เราจะพูดคุยเพิ่มเติมเกี่ยวกับฉบับล่าสุดนี้ในภายหลัง

กฎในตัว

เมื่อพูดถึงกฎการทำธุรกรรม มีวิธีหนึ่งที่ MultiChain แตกต่างจาก Fabric, Ethereum และ Corda โดยเฉพาะ MultiChain ต่างจากแพลตฟอร์มอื่นๆ เหล่านี้ มี abstractions ในตัวหลายตัวที่มีการสร้างบล็อคพื้นฐานสำหรับแอปพลิเคชันที่ขับเคลื่อนด้วยบล็อคเชน ต้อง นักพัฒนาให้เขียนโค้ดของตัวเอง นามธรรมเหล่านี้ครอบคลุมสามส่วนที่จำเป็นโดยทั่วไป: (a) สิทธิ์แบบไดนามิก (b) สินทรัพย์ที่โอนได้ และ (c) การจัดเก็บข้อมูล

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

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

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

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

กฎการทำธุรกรรม	ผ้า	มัลติเชน	Ethereum	Corda
รุ่น	สัญญา–ข้อความ	อินพุต-เอาต์พุต	สัญญา–ข้อความ	อินพุต-เอาต์พุต
ในตัว	ไม่มี	สิทธิ์ + สินทรัพย์ + สตรีม	ไม่มี	ไม่มี

determinism

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

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

มาดูกันว่าในทางปฏิบัติมีลักษณะอย่างไร อันดับแรกในโมเดลอินพุต-เอาต์พุต หากโหนดสองโหนดมีความคิดเห็นที่แตกต่างกันว่าธุรกรรมนั้นถูกต้องหรือไม่ โหนดหนึ่งจะยอมรับบล็อกที่มีธุรกรรมนั้นและอีกโหนดหนึ่งจะไม่ยอมรับ เนื่องจากทุกบล็อกเชื่อมโยงกลับไปยังบล็อกก่อนหน้าอย่างชัดเจน สิ่งนี้จะสร้าง "fork" ถาวรในเครือข่าย โดยมีโหนดอย่างน้อยหนึ่งโหนดไม่ยอมรับความคิดเห็นส่วนใหญ่เกี่ยวกับเนื้อหาของบล็อคเชนทั้งหมดตั้งแต่นั้นเป็นต้นมา โหนดในชนกลุ่มน้อยจะถูกตัดออกจากสถานะการพัฒนาของฐานข้อมูล และจะไม่สามารถใช้แอปพลิเคชันได้อย่างมีประสิทธิภาพอีกต่อไป

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

แหล่งที่มาของการไม่กำหนดขึ้น

ดังนั้นการไม่มีการกำหนดในโค้ดบล็อคเชนจึงเป็นปัญหาอย่างชัดเจน แต่ถ้าองค์ประกอบพื้นฐานของการคำนวณ เช่น เลขคณิต เป็นตัวกำหนด เราต้องกังวลเรื่องอะไร? ปรากฎว่าค่อนข้างบาง:

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

สี่แพลตฟอร์มบล็อกเชนของเราใช้วิธีต่างๆ ในการหลีกเลี่ยงข้อผิดพลาดเหล่านี้

การดำเนินการที่กำหนด

มาเริ่มกันที่ Ethereum กันก่อน เนื่องจากแนวทางของมันคือ "บริสุทธิ์" ที่สุด สัญญา Ethereum จะแสดงในรูปแบบวัตถุประสงค์พิเศษที่เรียกว่า “Ethereum bytecode” ซึ่งดำเนินการโดย Ethereum Virtual Machine (“EVM”) โปรแกรมเมอร์ไม่ได้เขียน bytecode โดยตรง แต่สร้างหรือ "คอมไพล์" จากภาษาการเขียนโปรแกรมที่เหมือน JavaScript ที่เรียกว่า Solidity (ภาษาอื่นๆ เคยมีให้ใช้งาน แต่หลังจากนั้นเลิกใช้แล้ว) Determinism รับประกันโดยข้อเท็จจริงที่ว่า Solidity และ Ethereum bytecode ไม่สามารถเข้ารหัสการดำเนินการที่ไม่ได้กำหนดไว้ได้ ง่ายขนาดนั้น

ตัวกรอง MultiChain และสัญญา Corda เลือกแนวทางที่แตกต่าง โดยการปรับภาษาโปรแกรมที่มีอยู่และสภาพแวดล้อมรันไทม์ MultiChain ใช้ JavaScript ที่ทำงานใน Google's V8 เอ็นจิ้นซึ่งเป็นแกนหลักของเบราว์เซอร์ Chrome และแพลตฟอร์ม Node.js แต่ปิดการใช้งานแหล่งที่มาของการไม่กำหนด ในทำนองเดียวกัน Corda ใช้ Java หรือ คอตลินซึ่งทั้งคู่ได้รับการคอมไพล์เป็น “Java bytecode” ซึ่งดำเนินการภายใน Java Virtual Machine (“JVM”) สำหรับตอนนี้ Corda ใช้ JVM ที่ไม่ได้กำหนดมาตรฐานของ Oracle แต่งานอยู่ระหว่างการบูรณาการa รุ่นที่กำหนด. ในระหว่างนี้ นักพัฒนาซอฟต์แวร์ที่ทำสัญญากับ Corda จะต้องดูแลไม่ให้มีการไม่กำหนดเงื่อนไขในโค้ดของตน

ความพิถีพิถันของ Ethereum เปรียบเทียบกับแนวทางวิวัฒนาการที่ดำเนินการโดย MultiChain และ Corda อย่างไร ข้อได้เปรียบหลักของ Ethereum คือการลดความเสี่ยง – เครื่องเสมือนที่สร้างขึ้นเพื่อจุดประสงค์นั้นมีโอกาสน้อยที่จะมีแหล่งที่มาของการไม่กำหนดโดยไม่ได้ตั้งใจ แม้ว่าการกำกับดูแลดังกล่าวสามารถแก้ไขได้โดยการอัปเดตซอฟต์แวร์ แต่ก็จะส่งผลเสียต่อห่วงโซ่ที่โชคไม่ดีพอที่จะเผชิญหน้า อย่างไรก็ตาม ปัญหาของ Ethereum ก็คือ Solidity และ EVM นั้นสร้างระบบนิเวศขนาดเล็กและเพิ่งเริ่มต้นในบริบทที่กว้างขึ้นของภาษาโปรแกรมและสภาพแวดล้อมรันไทม์ โดยการเปรียบเทียบ JavaScript และ Java คือ สองภาษายอดนิยมใน Githubทำงานบนอุปกรณ์ดิจิทัลหลายพันล้านเครื่อง และมีรันไทม์ที่ได้รับการปรับให้เหมาะสมกว่าทศวรรษ น่าจะเป็นเพราะเหตุนี้ Ethereum blockchain สาธารณะจึงกำลังพิจารณาการเปลี่ยนผ่านไปยัง eWASMซึ่งเป็นทางแยกที่กำหนดขึ้นของมาตรฐาน WebAssembly ที่เกิดขึ้นใหม่

การกำหนดโดยการรับรอง

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

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

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

การกำหนดระดับโดยการรับรองของ Fabric มีผลที่น่าสนใจหลายประการ ประการแรก สามารถเขียน chaincode ได้ในภาษาโปรแกรมต่างๆ มากมาย เนื่องจากไม่จำเป็นต้องปรับให้เข้ากับ determinism (ปัจจุบันรองรับ Go, Java และ JavaScript) ประการที่สอง รหัสลูกโซ่สามารถซ่อนจากผู้เข้าร่วมบางส่วนของ blockchain ได้ เนื่องจากจำเป็นต้องดำเนินการโดยลูกค้าและผู้รับรองเท่านั้น (ฐานข้อมูลนั้นสามารถมองเห็นได้ทั่วโลก) สุดท้ายและที่เด่นที่สุดคือ Fabric chaincode สามารถทำสิ่งต้องห้ามในสภาพแวดล้อม blockchain อื่นๆ เช่น การตรวจสอบสภาพอากาศโดยใช้ web API ออนไลน์ ในกรณีที่เลวร้ายที่สุด ที่ผู้รับรองทุกคนได้รับคำตอบที่แตกต่างจาก API นี้ ลูกค้าจะไม่สามารถได้รับการรับรองเพียงพอสำหรับผลลัพธ์เฉพาะใดๆ และจะไม่มีการทำธุรกรรมเกิดขึ้น (ควรสังเกตว่าสมาชิกในทีม Fabric ยังคง แนะนำ โดยใช้ตรรกะที่กำหนดขึ้นภายใน chaincode เพื่อหลีกเลี่ยงความประหลาดใจ)

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

determinism	ผ้า	มัลติเชน	Ethereum	Corda
รุ่น	การรับรอง	รันไทม์ที่ปรับเปลี่ยน	VM . ที่สร้างขึ้นตามวัตถุประสงค์	รันไทม์ที่ปรับเปลี่ยน
ภาษา	ไป + Java + JavaScript	JavaScript	ความแข็งแรง	จาวา + คอตลิน
การมองเห็นรหัส	คู่สัญญา + ผู้รับรอง	blockchain	blockchain	คู่สัญญา + ผู้อยู่ในอุปการะ
การบังคับใช้	ไม่	ใช่	ใช่	ไม่ (สำหรับตอนนี้)

การป้องกันความขัดแย้ง

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

สองรุ่น

เราสามารถเริ่มต้นด้วยการจัดกลุ่มแนวทางของ MultiChain และ Corda เพื่อแก้ไขปัญหานี้ด้วยกัน ตามที่อธิบายไว้ก่อนหน้านี้ ทั้งสองใช้โมเดลอินพุต-เอาท์พุตสำหรับการแสดงธุรกรรมและกฎของธุรกรรม ซึ่งแต่ละรายการอินพุตใช้เอาต์พุตของธุรกรรมก่อนหน้า สิ่งนี้นำไปสู่หลักการง่ายๆ ในการป้องกันความขัดแย้ง: ทุกผลลัพธ์สามารถใช้ได้เพียงครั้งเดียว ตัวกรอง MultiChain และสัญญา Corda สามารถพึ่งพาแพลตฟอร์มที่เกี่ยวข้องเพื่อบังคับใช้ข้อจำกัดนี้โดยสิ้นเชิง เนื่องจาก $10 ของ Alice แสดงโดยผลลัพธ์ของธุรกรรมก่อนหน้า กฎการใช้จ่ายครั้งเดียวนี้จึงหยุดส่งให้เธอทั้ง Bob และ Charlie โดยอัตโนมัติ

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

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

ผลลัพธ์เทียบกับสัญญา

จนถึงตอนนี้ เราได้เห็นเทคนิคที่แตกต่างกันสองแบบในการป้องกันธุรกรรมที่ขัดแย้งกัน – เอาต์พุตแบบใช้ครั้งเดียวใน MultiChain และ Corda และการตรวจสอบตามสัญญาใน Ethereum แล้วแบบไหนดีกว่ากัน?

เพื่อช่วยตอบคำถามนี้ ให้ลองพิจารณาตัวอย่างบัญชี “1 ใน 2 ลายเซ็นหลายลายเซ็น” ซึ่งถือ $100 ในนามของ Gavin และ Helen และอนุญาตให้คนใดคนหนึ่งใช้จ่ายเงินนั้นแยกกัน กาวินสั่งให้ใบสมัครของเขาจ่ายเงิน 80 ดอลลาร์ให้แก่ดอนน่า และไม่กี่วินาทีต่อมา เฮเลนต้องการส่ง 40 ดอลลาร์ให้เอ็ดเวิร์ด เนื่องจากมีเงินไม่เพียงพอสำหรับการชำระเงินทั้งสองรายการ ธุรกรรมเหล่านี้จะขัดแย้งกันอย่างหลีกเลี่ยงไม่ได้ ในกรณีที่ทั้งสองธุรกรรมได้รับการถ่ายทอด ผลลัพธ์จะถูกกำหนดโดยสิ่งใดก็ตามที่ทำให้เป็นอันดับแรกในห่วงโซ่ โปรดทราบว่าความขัดแย้งนี้คือ .ไม่เหมือนกับตัวอย่างของอลิซ โดยไม่ตั้งใจเนื่องจากไม่มีใครพยายามแหกกฎของแอปพลิเคชัน – พวกเขาแค่มีจังหวะที่โชคไม่ดี

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

ด้วยโมเดลอินพุท-เอาท์พุต ความขัดแย้งระหว่างธุรกรรมใดๆ สามารถมองเห็นได้โดยตรงที่แพลตฟอร์มบล็อคเชน เนื่องจากธุรกรรมทั้งสองจะพยายามใช้เอาต์พุตเดียวกันก่อนหน้านี้อย่างชัดเจน ใน MultiChain สิ่งนี้จะเกิดขึ้นทันทีที่ธุรกรรมของ Gavin ได้แพร่กระจายไปยังโหนดของ Helen โดยปกติจะใช้เวลาไม่กี่วินาทีหรือน้อยกว่านั้น ในคอร์ดา ทนายความของผู้ส่งออกจะปฏิเสธคำขอลงนามในธุรกรรมของเฮเลน เนื่องจากได้ลงนามในสัญญาของ Gavin แล้ว ดังนั้นเฮเลนจะทราบทันทีว่าการชำระเงินของเธอจะล้มเหลว (แม้ว่าทนายความของ Corda จะถูกแจกจ่ายออกไปเอง เธออาจต้องรอสองสามวินาทีเพื่อตอบกลับ) ไม่ว่าจะด้วยวิธีใด ไม่จำเป็นต้องรอให้ธุรกรรมได้รับการยืนยันและสั่งซื้อในบล็อคเชน

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

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

ชุดอ่าน-เขียน

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

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

แนวทางแก้ไขข้อขัดแย้งของ Fabric นั้นใช้ได้ดี แต่ในแง่ของประสิทธิภาพและความยืดหยุ่นนั้น รวมเอาสิ่งที่เลวร้ายที่สุดของสองรุ่นก่อนหน้านี้ เนื่องจากการรับรองจะแปลงธุรกรรมเป็นชุดการอ่าน-เขียนเฉพาะ การชำระเงิน 40 ดอลลาร์ของ Gavin และ Helen พร้อมกันแต่เข้ากันได้จะนำไปสู่ความขัดแย้งที่ Ethereum หลีกเลี่ยง อย่างไรก็ตาม Fabric ไม่ได้รับข้อได้เปรียบด้านความเร็วของโมเดลอินพุต-เอาต์พุต เนื่องจากผู้รับรองจะทำสัญญากับฐานข้อมูลเวอร์ชันล่าสุดที่ยืนยันโดยบล็อคเชน โดยไม่สนใจธุรกรรมที่ยังไม่ได้ยืนยัน ดังนั้นหาก Helen เริ่มชำระเงินภายในไม่กี่วินาทีหลังจาก Gavin แต่ก่อนที่ Gavin's จะได้รับการยืนยันบนบล็อคเชน Fabric จะสร้างธุรกรรมที่ขัดแย้งกันซึ่งโมเดลอินพุต-เอาท์พุตที่บริสุทธิ์จะหลีกเลี่ยง

การป้องกันความขัดแย้ง	ผ้า	มัลติเชน	Ethereum	Corda
รุ่น	ชุดอ่าน-เขียน	ใช้จ่ายครั้งเดียว	เช็คสัญญา	ใช้จ่ายครั้งเดียว
การตรวจสอบ	อิสระ	อิสระ	อิสระ	พรักานที่เชื่อถือได้
ความเร็ว	~10 วินาที (ยืนยัน)	~1 วินาที (การขยายพันธุ์)	~10 วินาที (ยืนยัน)	0~5s (ทนายความ)

ทางเลือกที่ซับซ้อน

ในงานชิ้นนี้ เราได้ทบทวนวิธีการต่างๆ มากมายที่ Corda, Ethereum, Fabric และ MultiChain จัดการกับความท้าทายที่สำคัญของ “สัญญาอัจฉริยะ” หรือรหัสแอปพลิเคชันที่ฝังอยู่ในบล็อคเชน และแต่ละแพลตฟอร์มมีคำตอบที่แตกต่างกันสำหรับคำถามหลักสามข้อของเรา: กฎการทำธุรกรรมแสดงอย่างไร? โค้ดถูกรันโดยกำหนดอย่างไร? และเราจะป้องกันความขัดแย้งได้อย่างไร?

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

กรุณาโพสต์ความคิดเห็นใด ๆ ใน LinkedIn.