Key concepts ของ Corda Part 1

สวัสดีครับ วันนี้ผมจะมาเล่าให้ฟังเกี่ยวกับ key concepts ของ corda ก่อนเราจะใช้มันเรามาเรียนรู้เกี่ยวกับ concept มันก่อนดีกว่าครับ

ดังนั้นในบทความนี้ผมคงจะไม่กล่าวถึง code เลยนะครับ ดังนั้นใครอยากรู้ว่าจะเริ่มต้นเขียน corda ยังไงหรืออย่างเห็นตัวอย่างการเขียนแบบเริ่มต้น ผมเคยเขียนไว้ก่อนหน้าแล้ว กดจากตรงนี้เบาๆ 1 ทีครับ

ผมจะ follow ตาม document ของ Corda เลย เลยนะครับ ซึ่งมีหลายคำมากที่เราต้องรู้จัก (Ref: https://docs.corda.net/key-concepts.html) ดังนั้นผมจะแบ่งเป็น part นะครับ

มาเริ่มกันเลยดีกว่า!!

Corda แบ่งเป็นหัวข้อตามนี้ครับถ้ากดเข้าไปจะเห็นคำอธิบายแต่ล่ะอันของ Corda นะครับ

• The network
• The ledger
• Identity
• States
• Contracts
• Transactions
• Flows
• Consensus
• Notaries
• Time-windows
• Oracles
• Nodes
• Tradeoffs

ใน part นี้ผมจะอธิบาย network, ledger, identity, state, contract และ transaction ครับ ลุย!!

The Network

โดยสรุปคือ network ของ corda จะประกอบไปด้วย node ต่างๆ ที่ใช้ JVM run-time ข้างในจะมี Corda services ที่จะคอยทำหน้าที่ execute request ต่างๆ ซึ่งรู้จักกันในชื่อ CorDapps ครับ

ซึ่งแต่ละ node จะคุยกันโดยมีตัวควบคุมชื่อว่า doorman ซึ่งการคุยกันนั้นจะไม่ใช่การคุยกับแบบกระจายออกไปให้ทุก node หรือ boardcast เพราะ Corda เป็น private network การคุยกันจะเป็นแบบ point-to-point, (คุยกันตัวๆ นะคร้าบ)

ในการจะเข้าไป join กับ network ได้นั้นต้องได้รับความเห็นชอบจาก doorman ก่อนนะ ถ้าพี่เค้าอนุญาติให้เราร่วมได้แล้วเค้าจะให้ root-authority-signed TLS certificate (เหมือนบัตรผ่านประตูเลย) ซึ่งได้จาก network’s permissioning serviceg

เจ้า certificate ตัวนี้จะเป็นใบรับรองว่า node เรานั้นมีตัวตนใน network นี้ซึ่งจะทำให้เราสามารถคุยกะชาวบ้านได้จ้า แต่ละ node ต้องคุยกับ notary services มันจะทำหน้าที่เหมือนคนคอยตรวจสอบความถูกต้องของ transaction ก่อนจะอนุญาติว่า transaction นั้นใช้งานได้ครับ

The ledger

เป็นเหมือนกับ database นะครับซึ่งแต่ละ node จะมีเป็นของตัวเองเพราะ concept ของ corda ไม่ได้ต้องการเก็บ data เป็นแบบเก็บข้อมูลทั้งหมดไว้ที่ศูนย์กลาง (single central store of data) ดังนั้นแต่ละ node ต้องจัดการกับ database ของตัวเอง แต่ละ record ที่เราเก็บลง database Corda เรียกว่า facts ซึ่งทุกๆ facts ที่จะ share กันระหว่าง node ต้องอ้างถึง contract ที่เป็น version เดียวกันเป๊ะๆ นะคร้าบ

จากรูปจะเห็นว่า Alice และ Bob จะ share ข้อมูลกันระหว่าง facts 1 และ 7 หมายความว่าแค่ 1 กับ 7 เท่านั้นที่ version ต้องตรงกันเป๊ะๆ อันอื่น I don’t care

คำถามคือจะทำให้เหมือนกันได้ไง

คือตอบคือ contact ไงครับ!!

Identity

Identities ใน Corda จะใช้สำหรับ legal identities หรือ service identities

legal identities จะใช้กับ parties(node) ใน transaction

service identities จะใช้กับ notary หรือ oracle คร้าบ

ซึ่ง Identities จะสามารถใช้ได้ทั้งแบบ well known และ confidential

ถ้าเป็น well known นั้นผมจะสามารถเห็น transaction ทั้งหมดที่อยู่ใน chain

ส่วน confidential ผมจะเห็นได้เฉพาะ transaction ที่เกี่ยวข้องกับ node ของผมเท่านั้นครับ

เดี่ยวผมจะยกตัวอย่างให้เห็นภาพนะครับ

ตัวอย่าง A → B → C → D

A ส่งของให้ B แล้ว B ส่งต่อให้ C สุดท้าย C ส่งต่อให้ D

สมมุติผมเป็น node D นะครับ

ถ้าเป็นแบบ well know ผมจะสามารถ เข้าถึง transaction ได้ทุกอัน (transaction ที่ A → B กับ B → C ผมก็เข้าถึงได้นะ)

แต่ถ้าเป็น confidential ผมจะเข้าถึงได้เฉพาะ transaction ที่ C ส่งมาให้ผมได้อันเดียวครับ (ถ้าใช้กับการ โอนเงิน ต้องแบบนี้เท่านั้น คุณคงไม่อยากให้ทุกคนเห็นแหล่งที่มาของเงินใช่ไหม!!)

ส่วนวิธีการนั้น

Well know ใช้แค่ public key อย่างเดียวในการสร้าง transaction

ส่วน confidential จะให้ private key + public key (ของคนที่เราคุยด้วย) มาสร้าง key ใหม่ครับ

States

State เป็น object ที่แก้ไขไม่ได้ ซึ่ง state จะเป็นตัวแทนของ facts ที่ node ที่เกี่ยวข้องรู้จักในช่วงเวลานั้นๆ ครับ (จำ facts ได้ไหมครับ facts ก็เหมือนกับ record ที่เราเก็บลง db แหละครับ)

ตัวอย่างข้อมูลใน state ที่ Alice ยืมเงิน Bob £10 ครับ

จากรูปจะเห็นว่าใน state มีข้อมูลเกี่ยวกับงานยืมเงิน และอีกสองอันที่สำคัญ อันแรกคือผู้เกี่ยวข้อง (paticipates) อีกอย่างคือ contact reference ซึ่งผู้ที่เกี่ยวข้องต้องใช้ contact version เดียวกันเป๊ะๆ นะครับ

อย่างที่บอกไปนะครับว่า state เป็น object ที่แก้ไขไม่ได้ดังนั้นเราไม่มีการ update นะครับการ update คือการ mark state ให้เป็น CONSUMED แล้วสร้าง state ใหม่ ที่เป็น UNCONSUMED

The vault

แต่ละ node ใน network มี vault เป็นของตัวเองจ้า ซึ่งมันใช้เพื่อทำการดึง state ทั้ง state ปัจุบัน (UNCONSIMED) และ state เก่าๆ (CONSUMED)

Contracts

Contract จะทำการตรวจสอบข้อมูลต่างๆ ใน transaction ว่าถูกต้องตามข้อกำหนดไหม ซึ่งถ้าถูกต้องทั้งหมดจึงจะได้รับการรับลองจากผู้เกี่ยวข้อง ซึ่งทุกๆ node ที่เกี่ยวข้องจะมี contract ที่จะใช้ในการตรวจสอบ transaction นั้นแต่ contract ทั้งหมดต้องเป็น version เดียวกันหรือเหมือนกันเป๊ะๆ นะครับ

การตรวจสอบ transaction

Contract จะทำการเอา input state และ output state ทั้งหมดที่อยู่ใน transaction นั้นมาทำการตรวจสอบว่าผ่านข้อกำหนดใน contract ไหม ซึ่งแต่ละ state ต้อง link กะ contract นะ (จำได้ไหมครับใน state จะมี contract reference อยู่) ซึ่งถ้าทั้งหมดถูกต้องจึงจะถือว่า transaction นั้นใช้ได้ และ transaction นั้นจึงจะได้รับการรับรอง (singed) และทำการเก็บลง ledger

Contract ต้องเขียนโดยใช้ภาษา JVM นั่นคือ ต้องใช้ Java หรือ kotlin เท่านั้นนะครับ

คำถาม เราจะเขียนข้อกำหนด (rule) ใน contract ยังไง

ตอบ เราก็ต้องรู้ requiremnet สิครับ แล้วก็นำ requirement นี่แหละมาเขียน เช่น

สมมุติเราจะสร้าง member เราอาจจะกำหนดข้อกำหนด (rule) ดังนี้

• ต้องมี member เกิดขึ้น
• สร้าง member ได้ทีละคน
• Member ที่จะเกิดขึ้นได้ต้องได้รับการรับรองจากผู้ที่เกียวข้องทุกคน

ซึ่งการทำงานของ contract นั้นผมจะยกตัวอย่างให้เห็นภาพนะครับ มันเหมือนกับการตรวจสอบในห้องปิดครับ คือไม่มีการไปติดต่อหรือดึงข้อมูลจากข้างนอกสิ่งที่มันมีคือ state ของ input และ output กับ rule ที่กำหนดขึ้นเท่านั้น ซึ่งถ้าทั้งหมดผ่านข้อกำหนดก็ใช้ได้ครับ ที่เค้า design มาแบบนี้ก็เพื่อความปลอดภัยครับ ดังนั้นข้อจำกัดของ contract คือถ้าเราอยากจตรวจสอบอะไรที่ไม่ใช่ input กะ output ที่ pass เข้ามาใน contract ทำไม่ได้เน้อ เช่น อยากตรวจสอบว่า node ที่จะสร้าง member ได้ต้องเป็น A เท่านั้น contract ทำไม่ได้จ้า

อ้าว!! แล้วทำที่ไหนดีล่ะ

คำตอบคือไปตรวจสอบใน flow นะครับ

Transactions

Corda ใช้ UTXO model(unspent transaction output) ใช้เพื่อทำการ update state บน ledger เพื่อให้ มันคง concept ว่า state ต้องห้ามแก้ไข

ซึ่งวิธีการก็คือ corda จะจัดการเอา state ทั้งหมดใน transaction มาจัดการ 2 แบบ

1. Mark state ที่เป็น input ให้เป็น CONSUMED
2. สร้าง state ใหม่จาก output ซึ่งเป็น UNCONSUMED

state ต่างๆ ที่อยู่ใน transaction สามารถที่จะ

• มีหลายๆ type อยู่รวมกันใน transaction เดียวได้ เช่น ใน transaction สามารถ มีทั้ง Bond และ Cash state ได้
• ใน transaction อาจจะไม่มี input หรือ ไม่มี output ก็ได้นะครับ
• สามารถใช้ในการรวม หรือแยก state ก็ได้เช่น input เป็นเงิน 10 บาท output อาจแยกเป็น 5 บาทสองก้อนก็ได้ครับ

การทำงานใน transaction ต้องเป็น atomic ซึ่งหมายความว่าการเปลี่ยนแปลงใน transaction นั้นต้องยอมรับทั้งหมดหรือ cancel ทั้งหมด concept เดียวกับ transaction ใน database เลยครับ

Transaction chains

เวลาเราจัดการกับ transaction หนึ่งๆ แน่นอนว่า output state ใน transaction ที่เรากำลัง process นั้นมันยังไม่เกิดขึ้น แต่ input(ถ้ามี)นั้นเราเราจะต้องเอามาจาก output ของ transaction ก่อนหน้า โดยเราจะมี reference สองอย่าง

1. Hash ของ transaction
2. index ของ output state

รูปภาพแสดง chain ของ transaction

จากในรูปจะเห็นว่า transaction มันจะ link กัน เป็น chain เลยครับ

Committing transactions

ในตอนเริ่มต้น transaction ที่เรากำลัง process นั้นมันจะยังไม่เกิดขึ้นจริงจนกว่าผู้ที่เกี่ยวข้องทั้งหมดที่เราใส่ไปตอนสร้าง command (เดี๋ยวผมจะอธิบาย command อีกที) จะทำการเซ็นต์รับรองว่าถูกต้องก่อน พอทุกคนรับรองเรียบร้อยจึงจะถือว่า transaction นั้นเกิดขึ้นจริง

แล้ว corda ก็จะทำการ update ledger ตามนี้ครับ

• mark all input ให้เป็น historic หรือ CONSUMED ซึ่งหมายความว่าไม่สามารถนำไปให้ใน transaction ที่จะเกิดขึ้นใหม่ได้อีกต่อไปครับ
• สร้าง current state ใหม่จาก output ซึ่งเป็น UNCONSUMED state อันนี้สามารถเอาไปอ้างถึงใน transaction ที่จะเกิดขึ้นใหม่ได้ครับ

การที่แต่ละ node จะ sign ว่า transaction นั้นๆทุกต้อง transaction นั้นต้องผ่านการตรวจสอบสองอย่างนี้นะครับ

1. Transaction validity: ต้อง valid ทั้ง transaction ที่กำลัง process และ transaction ที่ถูกเอามาอ้างถึงครับ ซึ่งเราจะดูจากว่า transaction ที่เกี่ยวข้องได้รับการ sign และ transaction ที่เรากำลัง process ผ่าน contract ครับ
2. Transaction uniqueness: transaction ที่เราเอามาอ้างถึงใน input ต้องไม่ถูกเอาไป commit หรือเอาไปใช้ใน transaction อื่นครับ

นอกจาก input และ output state transaction ยังมีส่วนประกอบอื่นๆ อีก 3 อย่าง

• Commands
• Attachments
• Timestamps

รูปแสดงส่วนประกอบทั้งหมดใน transaction ที่ Alice ทำการคืนเงินที่ยืมให้ Bob £5 โดยมี เอกสารอ้างอิง 2 ชุด และมีช่วงเวลาที่อนุญาติ transaction นี้เกิดขึ้น(timestamp)

Commands

แปลตรงๆ คือคำสั่ง ซึ่งมันคือคำสั่งที่เราจะใช้เพื่อทำให้เกิด state output จาก state input ครับ โดยเราจะทำการบอกว่า state inputs ผ่าน command นี้แล้วจะเกิดเป็น state outputs นี้

ซึ่งแต่ละ command จะต้องมี contact เพื่อใช้สำหรับ valdiate ความถูกต้องนะครับ

ยกตัวอย่างครับ

สมมุติใน transaction มีการทำงาน 2 อย่าง อันแรกคือ bond purchase(ซื้อตราสารหนี้ ) อันที่สองคือ coupon payment on a bond(จ่ายดอกเยี้ยให้ผู้ถือตราสารหนี้)

bond purchase : การซื้อ bond แน่นอนว่าเจ้าของต้องเปลี่ยนคนใช่ไหมครับ

coupon payment on a bond : เจ้าของเป็นคนเดิมแค่มีการจ่ายดอกเท่านั้น

เห็นไหมครับเราต้องแยกการทำงานสองอันนี้ออกจากกันเพราะการ valdiate ใน contract มันไม่เหมือนกันครับ

เอาล่ะเราลองมา focus ที่การจ่ายดอกอย่างเดียวลืมเรื่องการซื้อไปนะครับ

มาดูว่ามันจะเกิดอะไรได้บ้าง

• อย่างแรกคือ state ของ coupon ต้อง mark ว่าจ่ายแล้ว ซึ่ง participant มีแค่ alice คนเดียว
• อย่างที่สองต้องทีการโอนเงินจากผู้ออก bond ให้ผู้ถือ bond ซึ่ง participant จะเป็น alice กับ bob

แค่การจ่ายดอกเบี้ยเราก็แยก command ได้เป็น 2 แล้วครับ

ผมว่าหลายคนคงมีคำถามว่าเมื่อใหร่ที่ต้องแตก command ใหม่ ??

สำหรับผมจะแตก command ใหม่เมื่อการ validate ข้อมูลใน state มันแตกต่างกัน inputs outputs ต่างกัน หรือ พูดง่ายๆ มันเป็นคนละเรื่องกันครับ เช่น การ update bond กะการโอนเงินจะเห็นว่า state input output ต่างกัน validate ต่างกันชัดเจนว่าคนละ command ครับ

Attachments

ใน transaction จะมี attachment 2 แบบ แบบแรกจะมีหรือไม่มีก็ได้ครับซึ่ง attachment แบบนี้ก็คือเอกสารที่เราใช้อ้างอิงใน transaction นั่นแหละครับเช่น สัญญาต่างๆ แบบที่สองคือ contract ที่ใช้ใน transaction ซึ่งจะเก็บเป็น hash อีกอย่างนะครับ corda อนุญาติให้ upload ได้แค่ ZIP/JAR files เท่านั้นนะครับ

Time-windows

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

จบเรื่อง transaction แล้ว transaction นี่ค่อนข้างยาวนิสนึงนะครับ

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

สำหรับ key concept part 1 คงต้องจบลงตรงนี้ก่อนไว้พบกันใหม่ใน part 2 นะครับ ^ ^
สวัสดีครับ

Ref: https://docs.corda.net/key-concepts.html