Corda key concept Part 2

สวัสดีครับทุกท่าน บทความนี้เป็นการอธิบาย key concept ของ cordaครับซึ่งมันเป็น part ที่ 2 ใครที่ยังไม่ได้อ่าน part 1 หรือลืมไปแล้วว่ามันคืออะไร คลิ๊กตรงนี้ ครับ

ส่วนใครที่อยากได้ tutorial การเขียน corda ก็ คลิ๊กตรงนี้ ครับ

ใน part นี้ผมจะอธิบาย flow, consensus, notaries, time-windows, oracle, nodes และ tradeoffs ครับ ลุย!!

Flows

อย่างที่ผมเคยบอกไปครับว่า Corda จะใช้วิธีคุยกันแบบ point-to-point ไม่ใช่ broadcast ซึ่งมันหมายความว่าจะมีเฉพาะ node ที่เกี่ยวข้องเท่านั้นที่จะได้รับ transaction เพื่อทำการ verify ความถูกต้อง singed รับรอง แล้ว update ledger

อธิบายขั้นตอนนะครับ

  1. Alice สร้าง transaction ขึ้นมาแล้ว signed รับรองแล้วตรวจสอบ transaction นั้น
  2. Alice ส่ง transaction นี้ไปให้ผู้เกี่ยวข้อง ซึ่งในที่นี้คือ Bob
  3. Bob ตรวจสอบความถูกต้องแล้วก็ signed รับรอง
  4. Bob ส่ง transaction ที่ signed แล้วกลับมาให้ Alice
  5. Alice ตรวจสอบลายเซ็นต์ของ Bob ถ้าทั้งหมดถูกต้อง Alice กับ Bob ก็จัดการ update ลง ledger ตัวเองครับ

จะเห็นว่า node อื่นๆที่ไม่เกี่ยวข้องไม่จำเป็นต้องรับรู้ถึง transaction นี้เลย

หลายขั้นตอนเลยใช่ไหมกว่าจะสร้างได้ !!

ข่าวดีครับทั้งหมดที่ว่ามา Corda มี framework ไว้คอยจัดการ process เหล่านี้ให้แล้วสบายใจได้ครับ ซึ่ง corda เรียกมันว่า flow

ดังนั้นสรุปได้ว่า flow ก็คือขั้นตอนการทำงานที่ node คุยกันจนกระทั้ง update ledger นั่นเอง

เมื่อเรา implement flow code เรียบร้อยแล้วทำการ deploy เข้าไปที่ corDapps เราจะสามารถเรียก flow ของเราได้ ซึ่งการประมวลผลของ flow มันจะต่างจาก contracts เพราะ contrats ต้องการความปลอดภัยสูงจึงใช้ sandbox (อย่างที่เคยอธิบายไปในเรื่อง contracts) สิ่งที่เราจะ verify ใน flow ส่วนใหญ่จะเป็น input ของข้อมูลจาก I/O ข้อมูลจาก external system พวกนี้ครับ

flow ของเราสามารถ get data จาก external system ได้ ทำการรับ input (I/O) ได้นะครับ

ถ้าหากเราต้องการตรวจสอบความถูกต้องของ state เราควรทำใน contracts นะครับเพราะมันปลอดภัยกว่าเยอะ การจะแก้ contracts ต้องใช้ contracts upgrade อย่างเดียวซึ่งต้องทำทุก node เพื่อให้มันสามรถคุยกันได้ด้วย ซึ่งถ้าเอามาใส่ใน flow จะเสี่ยงกว่าเยอะเพราะผมสามารถสร้าง fake flow ที่ตัดบางเงื่อนไขออกไปขึ้นมาซึ่ง flow นี้อ้างถึง contract ปกติแล้วจัดการ deploy ใน node บาง node เพื่อสร้าง data ที่ไม่ถูกต้องได้ เช่น

สมมุติ ผมต้องการสร้างสินค้า ซึ่งจะให้ margin แก่ผู้ขาย 1 %

ถ้าผมเอา rule นี่ไปใส่ใน flow ไม่มีใน contract แล้ว hacker ดันรู้เข้า สิ่งที่เค้าจะทำเพื่อ hack คือสร้าง fake flow ในการสร้างสินค้าแล้วเปลี่ยน 1% เป็น 10% ซึ่งยังใช้ contract เดิมแล้ว deploy JAR file ของ flow นี้ลง node ที่เกี่ยวข้องก็สร้าง data ลง ledger ได้ซึ่งถ้าเป็นแบบนี้หมายความว่าเราแย่แล้ว!! แต่ถ้าเรา check rule นี้ใน contract มันจะดีกว่าเยอะเพราะถ้า hacker เปลี่ยน contract จะทำให้ version ของ contract ที่เอามา reference นี้มันจะไม่ตรงกะ node อื่นๆ ทำให้มันใช้งานไม่ได้ครับ

Flow สามารถ เรียก flow อื่นๆ เรียกว่า subflow ซึ่ง parent ต้องรอจนกระทั่ง subflow return มาจึง process ต่อได้ครับ

อย่างที่บอกครับว่า corda ไม่ได้ใจร้ายให้เราทำเองหมด เค้ามี libray ที่เกี่ยวกับการ process flow ให้เราเรียกใช้งานได้ครับ เช่น

  • การรับรองและการเก็บ transaction ลง ledger
  • ล่ารายเซ็นต์จาก counterparty nodes
  • ตรวจสอบ chain ของ transaction

อันนี้เป็น link flow library ครับ Flow library.

อีกอย่างนะครับ node สามารถ run หลายๆ flow ได้พร้อมกัน

Consensus

Transaction ที่สร้างขึ้นมานั้นจะ valid และสามรถ update ลง ledger ได้นั้นจะต้องผ่าน consensus ทั้ง 2 แบบ

1. Validity consensus

คือต้องผ่านการตรวจสอบของ contracts และได้รับการ signed รับรองจากผู้ที่เกี่ยวข้องทั้งหมด ซึ่งการตรวจสอบจะไม่ได้ตรวจสอบแค่ transaction ที่สร้างใหม่เท่านั้น แต่ต้องผ่านการตรวจสอบทั้ง chain

จากรูป Alice จะโอนเงินให้ Bob เพื่อใช้หนี้ที่ยืมมา นอกจากจะตรวจสอบ transaction ของการโอนเงินแล้วยังต้องตรวจสอบย้อนกลับว่า input state ที่เป็นเงินที่ได้มาจาก Dan นั้นถูกต้อง และเงินที่ Dan ได้มาจาก Cahrlie มาจากแหล่งที่ถูกต้อง โดยทั้งหมดต้องได้รับการ signed รับรอง

2. Uniqueness consensus

ลองนึกภาพดูนะครับถ้าผมมีเงิน 1,000,000 แล้วผมโอนเงินล้านนี้ให้ A 800,00 ให้ B 900,000 ในเวลาพร้อมๆกันซึ่งแน่นอนว่า transaction นี้มันจะผ่านการตรวจสอบใช่ไหมครับเพราะตรวจย้อนหลังเงินนี้ก็มาจากแหล่งที่ถูกต้อง

ดังนั้นเราต้องมีใครสักคนมาคอยตรวจสอบความเป็น uniqueness ซึ่งก็คือถ้ามี input ที่ถูกใช้ไปแล้วใน transaction อื่นต้อง detect ได้ว่ามันเป็น double spend ซึ่งคนทำหน้าที่นี้ก็คือ Notary node นั่นเอง

Notaries

อย่างที่ผมได้บอกไปเมื่อหัวข้อที่แล้วว่า notary ทำหน้าที่คอยตรวจสอบความเป็น unique ของ input state ใน transaction ว่ามีการถูกใช้ใน transaction อื่นไหม ( uniqueness consensus) เพื่อป้องกัน double spend ซึ่ง transaction ที่ผ่านการตรวจสอบจาก notary แล้ว notary จะ singed รับรองแต่ถ้าตรวจสอบแล้วไม่ผ่านก็จะ rejected ดังนั้นเราจะมั่นใจได้ว่า transaction ที่ผ่านการ signed จาก notary จะไม่มีเหตุการณ์ double spend แน่นอน!!

Consensus algorithms

Corda อนุญาติให้เราเลือก algorithm ในการตรวจสอบได้นะครับ ซึ่งก็แล้วแต่ว่าเราจะเลือกแบบไหนซึ่งมันก็อาจขึ้นกับว่าเราต้องการให้มัน scale ได้ ต้องการความน่าเชื่อถือ หรือต้องการความรวดเร็ว

เกี่ยวกับ notary เราจะทำการเลือกได้ 2 อย่างครับ

  1. Structure : เราอาจมี notary ตัวเดียว หรือมีหลายตัว ซึ่งถ้ามีหลายตัวเราก็เลือกได้อีกว่าเราจะให้ notary เชื่อการตรวจสอบจากตัวอื่นหรือไม่เชื่อก็ได้ กรณีที่เราเลือกให้ไม่เชื่อหมายความว่า transaction ที่ได้รับการ signed รับรองจาก notary ตัวอื่นแล้วเมื่อถูกส่งมาถึง notary ของเรา เรายังคงต้องตรวจสอบใหม่อีกที
  2. Consensus algorithm : เราเลือกได้ว่าจะให้ notary จะใช้ algorithm RAFT (เร็วแต่ต้องเชื่อ notary อื่นๆ) หรือ BFT (ช้าเพราะไม่เชื่อ notary อื่นๆ)

ถ้าอย่างรู้ข้อมูลเพิ่มเติมเกี่ยวกับ RAFT คลิ๊กตรงนี้เลยครับ

Multiple notaries

Corda อนุญาติให้แต่ละ notary ใช้ Consensus algorithms ที่แตกต่างกันได้

ข้อดีของการมี notary หลายตัวก็คือ

  • Privacy: Corda อนุญาติให้แต่ละ notary ใช้ Consensus algorithms ที่แตกต่างกันได้ และอนุญาติให้แต่ละ node เลือกได้ว่าจะให้ notary ไหนตรวจสอบ transaction ของตน
  • Load balancing: ทำให้ perfomance ดีขึ้น
  • Low latency: สามารถใช้ notary ที่อยู่ใกล้กับ node ที่เกี่ยวข้องเพื่อให้คุยกันได้เร็วขึ้น

Changing notaries

โดยปกติแล้วการตรวจสอบ state input จะใช้ notary เดิมในการตรวจสอบ เช่น stateA เคย notaries โดย notaryA เมื่ออ้างถึง stateA ก็ควรจะให้ notaryA ตรวจสอบ แต่เราสามารถเปลี่ยน notary ได้ เพราะ ในการสร้าง transaction หนึ่งๆจะมี notary ได้แค่อันเดียว ดังนั้นทุกๆ state ที่อยู่ใน transaction นั้นจะต้องถูก notaties โดย notary ที่กำหนดตอนสร้าง transaction ดังนั้น state ที่อยู่ข้างในจะต้องถูกเปลี่ยน notary ก่อนนะครับ (เราต้องเรียก flow ในการเปลี่ยน notary ให้แต่ละ state ใน transaction ให้มาใช้ notary ที่เรากำหนดตอนสร้าง transaction ก่อนนะครับ)

Time-windows

เป็นช่วงเวลาที่เราใช้บอกว่า transaction นั้นจะ valid หรือไม่ participants node และ notary node จะเช็ค time-window ที่ Initiator node ใส่เข้าไปใน transaction ในการ validate ว่า transaction นั้น valid ไหม

time-window มี 3 แบบ

  1. valid ถ้า transaction เกิดในช่วงเวลาที่กำหนด
  2. valid ถ้า transaction เกิดก่อนจุดที่กำหนด
  3. valid ถ้า transaction เกิดหลังจุดที่กำหนด

Oracles

ในการ validate transaction บางครั้งเราอาจต้องการข้อมูลจากภายนอกเช่น อัตราการแลกเปลี่ยน ต่อไปจะเรียกว่า fact นะครับ ซึ่งถ้าเราปล่อยให้แต่ล่ะ node validate กันเองบาง node อาจบากว่า ok ถูกต้อง ในขณะที่บาง node อาจมองว่ามันผิด ซึ่งอาจมีปัญหาได้ ดังนั้นเราต้องการคนกลางสักคน นั่นก็คือ Oracle !!

Oracle เป็นอีก node นึงซึ่งทำหน้าที่ sing รับรอง fact ใน transaction ถ้าหากว่า fact ที่ส่งมาให้ oracle validate มันถูกต้อง oracle ก็ จะ signed รับรอง transaction ให้ เช่น oracle จะเช็คว่าถ้า “อัตราแลกเปลี่ยน” ถูกก็จะ sign ให้เป็นต้น ดังนั้นหาก node ต้องการใช้ validate fact ใน transaction ก็จะส่ง request command ไปให้ oracle validate ถ้าหากว่า oracle ตรวจสอบแล้วถูกต้องก็จะ sign กลับมาให้เราก็สามารถใช้งานได้อย่างสบายใจไเ้ครับ

oracle อาจใช้ในเชิงพาณิชย์ ได้ด้วยน้า โดยเก็บค่าธรรมเนียมการตรวจสอบ

Transaction tear-offs

อย่างที่กล่าวไปข้างต้นครับว่า oracle จะทำหน้าที่ตรวจสอบแค่ fact ไม่ใช่ทั้ง transaction ดังนั้น หากเราต้องส่ง transaction ทั้งหมดมามันก็จะมีประเด็นเรื่อง privacy risk ได้

ดังนั้น Corda จึงเลือกใช้ Merkle tree เพื่อทำการตัดส่วนที่ oracle ไม่จำเป็นต้องเห็นออกครับเรียกว่า “tear off”

Merkle tree รู้จักกันดีและถูกนำมาใช้อย่างแพร่หลายในการตรวจสอบความถูกต้องของข้อมูล ในระบบ peer-to-peer networks, blockchain systems และ git

หลังจากที่ oracle sing รับรอง ไปแล้ว ถ้ามีการแก้ไขส่วนใดๆ ใน transaction จะถือว่าการ sign เป็นอันโมฆะ

มาดูกันหน่อยว่า transaction merkle tree ทำงานยังไง

H คือ sha256 function

“+” การต่อ string กัน

เราจะทำการแตกส่วนต่างๆ ของ transaction เป็น node ย่อยๆ แล้วเอาแต่ละอันผ่าน sha256 function นะครับ แล้วเอาต่อของมันมาต่อกันก่อนเข้า sha256 function อีก ตามรูป เอาผลลัพธ์ของ a ที่ผ่านการเข้ารหัส มาต่อกับผลลัพธ์ของ b ที่ผ่านการเข้ารหัส แล้วเข้ารหัสอีกทีได้ node ทำไปเรื่อยๆ จนได้ root node นั้นคือ transaction id

ถ้าเรามีการแก้ไขบาง node ย่อมทำให้ค่า transaction id เปลี่ยนไปมันเลยเอามาใช้ตรวจสอบได้ว่าข้อมูลนั้นถูกแก้ไขไหม

Hiding data

อย่างที่บอกว่าเราสามารถ tear off transaction แล้วส่งเฉพาะที่ oracle ต้องใช้ในตรวจสอบมาได้ครับ ซึ่งส่วนที่ตัดทิ้งไปก็ส่งเป็น hash มาเลยครับ เท่านี้เราก็สามารถตรวจสอบได้ว่า node ลูกที่เรากำลังตรวจสอบมันถูกต้องไหมโดยการหา root transaction id และเทียบกับ original ที่ส่งมาให้ (initiator ส่งมาให้ oracle)

Nodes

Node แต่ละอันใน Corda ใช้ระบบปฏิบัติการ JVM ที่มีความเฉพาะ (unique identity) บนระบบ network หนึ่งๆ ซึ่งแต่ละ node จะมี Corda services และ CorDapps อยู่ในนั้น

รูปแสดง โครงสร้างของ node

The core elements of the architecture are:

ส่วนประกอบสำคัญที่มีในแต่ละ node :

  • Persistence layer เป็นส่วนที่ใช้ในการเก็บข้อมูล
  • Network interface เป็นส่วนที่ใช้ในการติดต่อกับ node อื่นๆ
  • RPC interface เป็นส่วนที่เป็นให้เราสามารถคุยกับ node ของเราครับ
  • Service hub เป็นส่วนที่ช่วยให้ flow เข้าถึง service อื่นๆ ของ corda ได้ครับ
  • Cordapp interface และ provider เป็นส่วนที่ใช้ในการ implement code และ ติดตั้ง CorDapps

Persistence layer

Persistence layer มีสองส่วนนะครับ:

  • Vault เป็นส่วนที่ node ใช้ในการติดต่อกับ state (state map กับข้อมูลใน db) ทั้ง stat ปัจจุบัน และที่ CONSUMED ไปแล้วครับ
  • Storage service เป็นที่ที่ใช้เก็บ transactions attachments และ flow checkpoints (เมื่อมีการใช้ @Suspendable บนหัว function)

Network interface

การจะคุยกับ node อื่นๆ ใน network ผ่าน flow เราจะต้องคุยผ่าน network interface ครับ เราคุยตรงไม่ได้ครับ

RPC interface

การที่เราจะติดต่อกับ node ของเราเราจะคุยผ่าน RPC (Remote Procedure Calls) ถ้าอยากรู้ว่า Corda provide method อะไรให้เราเรียกใช้ได้บ้างดู document ได้ที่นี่ครับ API: RPC operations

The service hub

การจะเรียกใช้ service ต่างๆ ตอนที่ flow ทำงานภายใน node นั้นเราจะเรียกใช้ผ่าน serviceHub

Services สำคัญที่ Corda provide ให้ :

  • ข้อมูลของ node อื่นๆ ใน network และ service ที่ node อื่นๆมีให้ใช้
  • การเรียกใช้งาน vault และการเก็บข้อมูล
  • การเข้าถึงและการสร้าง public-private key
  • ข้อมูลของ node ตัวเอง
  • เวลาปัจจุบัน

The CorDapp provider

เป็นส่วนที่เราใช้ในการ implement ว่าจะให้ node เราทำงานอะไรบ้างครับ

ใน node หนึ่งๆ จะมี CorDapps หลายๆตัวติดตั้งไว้ให้เป็น default เพื่อใช้ทำงานบางอย่าง เช่น :

  • การรับ transaction และ attachments จาก node อื่นๆ ที่เกี่ยวข้อง (counterparties)
  • การ Upgrade contracts
  • การ Broadcast เพื่อยืนยันให้ counterparties update ข้อมูลลง ledger ตัวเอง
เอาล่ะครับเรื่องสุดท้ายของ key concepts แล้วครับ

Tradeoffs

Permissioned vs. permissionless

Blockchain ทั่วไปเป็นแบบ permissionless คือใครจะเข้ามา join หรือออกก็ได้แต่ Corda เป็นแบบ permissioned คือจะอนุญาติให้ node ที่เกี่ยวข้องเข้ามา join ได้ โดยมี doorman เป็นคนควบคุมครับ ซึ่งข้อดีของ permissioned ก็คือ

  • กันผู้ไม่เกี่ยวข้องเข้าถึงข้อมูลต่างๆ
  • เรารู้ข้อมูลของ node อื่นๆ ที่เกี่ยวข้องทำให้เราสามารถตกลงแก้ไขปัญหาต่างๆกันได้โดยใช้สัญญา และระบบกฎหมาย
  • ป้องกันการ Sybil attacks

Note: Sybil Attacks คือ รูปแบบการโจมตีเครือข่ายทางคอมพิวเตอร์ที่เกิดขึ้น โดยการสร้างตัวตนหลอกขึ้นมาในระบบ peer-to-peer networs REF

Point-to-point vs. global broadcasts

ระบบ blockchain networks ทั่วไปจะ broadcast ทุกๆ message ไปให้ทุกคนใน network เพราะว่า 2 เหตุผลครับ

  • มันไม่รู้ว่าใครเกี่ยวข้องบ้าง
  • ให้ทุกคนรับรู้ทุกๆ transaction เพื่อป้องกันเรื่อง double-spends

ซึ่งแน่นอนการกระจายทุกๆ เรื่องให้ทุกคนรับรู้คงไม่ดีแน่เพราะมันเสี่ยงเรื่องการรั่วไหลของข้อมูลสำคัญใช่ไหมครับ ดังนั้น Corda จึงส่ง transaction ให้เฉพาะผู้ที่เกี่ยวข้องเท่านั้นซึ่งผู้พัฒนาต้องกำหนดว่า message นี้จะส่งให้ให้ใครและส่งเมื่อไหร่และให้ notaries node คอยจัดการเรื่อง double-spends

Corda มีการใช้เทคนิคอื่น ๆ เพื่อเพิ่มความเป็นส่วนตัวบนเครือข่าย เช่น

  • Transaction tear-offs: Transactions ถูกออกแบบให้สามารถ sign รับรองได้โดยไม่ต้องเปิดเผยช้อมูลทั้งหมดใน transaction โดยการใช้ Merkle tree
  • Key randomisation: Corda provide method เพื่อให้เราสร้าง keypair ขึ้นมาใหม่เพื่อใช้ใน transaction นั้นๆเพื่อกันไม่ให้คนอื่นรู้ว่า transaction นั้นมีใครเป็นผู้เกี่ยวข้องบ้าง

UTXO vs. account model

Corda ใช้ UTXO (unspent transaction output) model นั้นคือเราต้อง set state input ใน transaction เป็น CONSUMED แล้วสร้าง state ใหม่จาก output state ให้เป็น UNCONSUMED

Account model สามารถอัพเดต request ใหม่ลงไปใน state เดิมได้เลย

ดังนั้นข้อดีของ UTXO ที่เห็นได้ชัด ถ้า transaction หลายๆอัน มีการเรียกใช้ input คนล่ะตัวกัน มันสามารถทำงานแบบ parallel กันได้แต่ถ้าเป็น Account model มันจะทำงานแบบ sequential ดังนั้น UTXO Model จึงรองรับ transactions-per-second ได้มากกว่าครับ

Code-is-law vs. existing legal systems

สถาบันการเงินต้องการแก้ไขปัญหาความขัดแย้งต่างๆ โดยใช้ระบบสักฎหมายที่มีอยู่ Corda จึงออกแบบมาเพื่อ support เรื่องนี้โดย

  • ใช้ permissioned networks หมายความว่าเราจะรู้ว่าผู้ที่เกี่ยวของเป็นใครบ้าง
  • Code contracts ทั้งหมดสามารถสร้างขึ้นมาจากเอกสารตามกฎหมายซึ่งใช้ในการแก้ไขข้อขัดแย้งต่างๆ ได้

Build vs. re-use

Corda พยายามใช้ technologies ต่างๆที่มีอยู่เดิมให้มากที่สุด แทนที่จะสร้างใหม่ เพื่อให้ในการพัฒนา platform เช่น:

  • Standard JVM programming languages
  • SQL databases
  • Message queue implementations

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

_________________________________________________________________

ผมขอจบเรื่อง key concepts ของ Corda ไว้เท่านี้ครับ

ขอบคุณทุกท่านที่ติดตามครับ สวัสดีครับ