ทุกวันนี้มีแพลตฟอร์ม blockchain สำหรับองค์กร (Enterprise) อยู่เป็นจำนวนมาก (เท่าที่รู้ก็จะ 10 กว่าตัวเข้าไปแล้ว) แต่ตัวที่มีการใช้งานกันอย่างแพร่หลายก็ยังมีอยู่แค่ไม่กี่ตัวเท่านั้น โดยตัวหนึ่งที่ผมได้พูดถึงไปแล้วก็คือ Corda และวันนี้ blockchain อีกตัว ที่ผมจะมาพูดถึง ก็คือ Quorum ที่เป็น Ethereum for enterprise platform อีกตัวที่น่าสนใจมากๆ
ทำไมจึงควรใช้ Quorum Blockchain?
- ใช้วิธีการเดิมแบบ Ethereum ทำให้ไม่ต้องศึกษาการเขียน Smart Contract ใหม่ หรือ การทำงานใหม่ (Solidity , Web3) เหมาะมากกับองค์กรที่ต้องการความรวดเร็วในการพัฒนา Smart Contract เพราะ Smart Contract ของ Ethereum มี Learning Curve ที่น้อยเมื่อเทียบกับ CorDApp (Corda) หรือ Chaincode (Hyperledger) ที่มีความซับซ้อน และความยุ่งยากในการพัฒนามากกว่า
- มีคุณสมบัติ PrivateFor เพื่อสร้าง Permissioned ให้กับ Smart Contract ได้ด้วย เหมาะกับองค์กรที่ต้องการเก็บข้อมูลที่มี Privacy สูงระหว่างองค์กร และยังมีความยึดหยุ่นสูง เพราะแต่ละองค์สามารถเลือกได้ว่า ต้องการให้ทุกคนในเครือข่ายรู้ทั้งหมด หรือ รู้แค่เฉพาะที่เกี่ยวข้อง โดยไม่จำเป็นต้องปรับแต่ง Smart Contract ใหม่ หรือ สร้างเครือข่ายใหม่
- สามารถนำคุณสมบัติใหม่ๆ ของ Ethereum มาใช้งานได้ทันที เนื่องจาก Ethereum เป็น Open Source จึงมีนักพัฒนาจำนวนมากทั่วโลก กำลังช่วยกันพัฒนาและปรับปรุงทั้งประสิทธิภาพ และ ความปลอดภัยของ Ethereum จึงทำให้ Quorum เองที่เป็น Ethereum fork มีการอัพเดตอยู่ตลอดเวลาไปด้วย
- ประสิทธิภาพสูง เนื่องจาก Quorum มีการออกแบบให้เหมาะสมกับเครือข่ายองค์กร โดยมีใช้ Consensus ที่ลักษณะคล้ายกับ PBFT ของ Hyperledger ที่ค่อนข้างมีประสิทธิภาพ
ทำไมจึงไม่ควรใช้ Quorum Blockchain?
- ความปลอดภัยอาจไม่สูงเท่ากับ Corda หรือ Hyperledger เนื่องจาก Ethereum ถูกพัฒนาในรูปแบบ Public Blockchain ซึ่งความสามารถต่างๆของ Ethereum ก็ยังต้องทดสอบด้านความปลอดภัยเพิ่มเติมอีกก่อนจะถูกนำมาใช้ใน Quorum
- ประสิทธิภาพด้าน TPS อาจจะน้อยกว่าเมื่อเทียบกับแพลตฟอร์ม DLT อื่นๆ อย่าง Hyperledger หรือ Corda
- ถึงแม้ว่าจะมีจุดเด่นที่ Learning Curve ในการศึกษา Solidity จะน้อยแต่ก็ยังมี Learning Curve ที่มากในการทำความเข้าใจแพลตฟอร์ม Ethereum
- เนื่องจากเป็น Blockchain ที่ถูกปรับแต่งมาจาก Ethereum ทำให้มีฟีเจอร์บางอย่างที่ไม่จำเป็น เมื่อนำมาพัฒนาสำหรับใช้ในองค์กรแบบปิด
หลังจากที่ได้รู้ข้อดี ข้อเสียต่างๆของ Quorum กันไปแล้ว งั้นเรามาทำความรู้จักกับ Quorum กันดีกว่า ว่าตกลงแล้ว มันคืออะไรกันแน่??
Quorum Blockchain
Quorum Blockchain คือ ระบบ Blockchain ที่ถูกออกแบบมาจาก Ethereum Blockchain โดยเป็นการนำ Ethereum มา fork เพื่อใช้งานในด้าน financial Services industry โดยจะเพิ่มความสามารถด้าน Permissioned หรือ Private Blockchain เข้าไปให้ Ethereum (ปกติ ETH เป็น Public Blockchain อย่างเดียว)
โดยคุณสมบัติหลักๆ คือ
- Transaction and Smart Contract Privacy คือ การทำ Transaction และ สร้าง Smart Contract แบบ Permissioned
- Multiple Voting-based Consensus Mechanism
- Network / Peer Permissions Management
- Higher Performance
และองค์ประกอบหลักๆ คือ
- Quorum Node (Modifier Geth Client)
- Constellation (Transaction Manager and Enclave)
โดยแผนภาพ Logical Architecture Diagram ดังภาพ
== Quorum Node
Quorum Node จะเป็นการนำ Go-Ethereum (Geth) มาปรับปรุงใหม่ โดยจะนำ ระบบหลักๆของ ETH มาดัดแปลง ดังนี้
- ‘Proof of Work’ Consensus มาดัดแปลงเป็น QuorumChain Consensus โดยอาศัย Vote-based Consensus Mechanism หรือ Raft Consensus
- ระบบ P2P Layer จะเพิ่มระบบ allow connection to/form permissioned node
- ระบบ ‘Global State Root’ ถูกแทนที่ด้วย The Block Generation logic
- ส่วน Header ของ ‘Global State Root’ จะถูกปรับเป็น The Block Validation Logic แทน
- The State Patricia สามารถแยก (Split) เป็นแบบ 2 แบบ
- Public state trie = Permissionless
2. Private state trie = Permissioned
- โดย Block Validation logic จะถูกใช้เพื่อ handle ‘Private Transaction’
- ระบบ Pricing of gas ถูกตัดทิ้ง แต่ก็ยังมีระบบ Gas อยู่ แต่จะไม่ถูกใช้งาน เนื่องจากยังต้องมีระบบพื้นฐานของ Ethereum อยู่
== Constellation
Constellation คือ ระบบ General-purpose system เพื่อให้การ submit information มีความปลอดภัย โดยใช้ระบบ MTA (Message Transfer Agent) โดยข้อมูลจะทำการ Encrypt ด้วย PGP (Pretty Good Privacy) เพื่อเข้ารหัส และยืนยันตัวตนผ่าน Email หรืออื่นๆ โดยจะเป็นโหนดเรียก Constellation Node (มีหน้าที่ Private Transaction Manager และ Enclave)
Constellation จะประกอบด้วย
- Transaction Manager คอยทำหน้าที่จัดการตัว Transaction Privacy และ จัดการว่า Node ใดบ้างจะได้ allow ให้ Decrypt Data ที่ถูก Store อยู่บน Quorum Chain
ระบบจะให้ทุก Node ถือข้อมูลแต่มีแค่บาง Node ที่จะมองเห็นข้อมูลได้ ซึ่ง Constellation จะคอยทำหน้าที่จัดการส่วนนี้
- The Enclave คือ ในการทำงานของ Distributed Ledger Protocols จะอาศัยการทำ Cryptography เพื่อ Encryption ตัว Transaction และทำ Participant authentication โดยที่ข้อมูล Transaction จะถูกเก็บรักษาไว้ (Historical data preservation)
โดย Enclave จะทำหน้าที่ช่วย Transaction Manager ในการเข้ารหัส และ ถอดรหัส เพื่อเพิ่มความปลอดภัย (Privacy)ให้กับระบบ (ทำหน้าที่ Encryption / Decryption)
Architecture Layer Diagram มีลักษณะดังภาพ
โดยในการทำงานของ Quorum ในปัจจุบัน (เวอร์ชั่นขณะที่กำลังเขียนคือ 2.4.0v)
Consensus
Consensus หลักๆ ของ Quorum คือ
- Raft Consensus
- Istanbul BFT
- QuorumChain Consensus (ปัจจุบันไม่ได้ใช้งานแล้ว แต่ถ้าใครสนใจ ผมเขียนอธิบายทิ้งไว้ ท้ายบทความแล้วครับ)
Quorum Block Structure
- Global transaction hash , hash of all transaction in a block (both private and public)
- The public state root hash
- Block Maker’s signature in the ExtraData field
1. Raft Consensus
เป็นอีกรูปแบบหนึ่งของ quorum consensus
Node แต่ละ Node จะมีได้ 3 สถานะ (state)
- Follower State
- Candidate State
- Leader State
รายละเอียดคร่าวๆ การทำงานของ Raft
โดยทุกๆ Node จะเริ่มต้นที่ follower state ถ้า follower state จะเปลี่ยนตัวเองเป็น Candidate state ทุกๆ Candidate Node จะประกาศไปยังระบบเพื่อหา Voter จาก Node อื่นๆ และ Node อื่นๆ จะ reply vote กลับมายังระบบ Node ที่ได้รับ vote มากที่สุด จะกลายเป็น Leader เรียกกระบวนการนี้ว่า Leader Election
เมื่อกลายเป็น Leader Node แล้วทุกๆ การเปลี่ยนแปลงจะถูกส่งไปที่ Leader และทุกๆ การ Change ของ Leader จะถูกเพิ่มเข้าไปใน Node’s log แต่จะยังไม่ถูกส่งไปยัง Node อื่นๆ หลังจากนั้น Leader จะทำการส่ง log ไปยัง follower Node ถ้ามี Follower Node มากพอ ที่ยอมรับข้อมูลกับ Log ที่ส่งให้
และ ตอนนี้ทุกๆ node จะอยู่ใน state เดียวกับ Leader node แต่ยังไม่ยืนยันการ commit (uncommit)
เมื่อทุกๆ Node ยอมรับแล้วว่า log นี้ถูกต้อง Leader ก็จะทำการ notifies ไปยัง follower เพื่อยืนยันการเก็บข้อมูล log (committed) เรียกกระบวนการนี้ว่า Log Replication
โดยเป็นกระบวนการส่งข้อมูลทั้งหมดใน System State
รายละเอียดของกระบวนการ Leader Election
กระบวนการ Leader Election จะมีการนำ timeout เข้ามาเกี่ยวข้อง แต่ละ node จะถูก random timeout ขึ้นมา (election timeout) โดยถ้ารันจนถึง election timeout จะกลายเป็น Candidate (โดย timeout อยู่ในช่วง 150ms — 300ms) และเมื่อเข้า Candidate state ก็จะเริ่ม Election term ซึ่งมีขั้นตอนดังนี้
- Vote ฉันหน่อย (Vote message to other node)
- ทุกๆ node จะรับ vote message และทำการตอบกลับ
- กลายเป็น leader (ถ้า vote มากที่สุด)
- Leader ส่ง Append Entry message ไปยัง follower
- โดยจังหวะของการส่ง entry message จะส่งตามจังหวะหัวใจ (Heartbeat timeout) และทุกๆ follower ก็จะตอบกลับไปในจังหวะเดียวกัน (ตอบกลับ append entry message)
- Election term จะจบลงเมื่อ Follower หยุดการตอบกลับไปยัง Leader เพราะ Leader หยุดส่ง append entry message (Follower stops receiving heartbeats) และกลายเป็น Candidate
- กระบวนการ re-election จะเริ่มต้นใหม่
ในกรณี มี 2 node เข้าสู่ Candidate state พร้อมกัน จะส่งผลโหวตไปพร้อมกัน โดยถ้า follower ได้รับ vote message จาก 2 node พร้อมกัน follower จะตอบกลับไปทั้ง 2 message แต่เมื่อได้รับ vote message แล้วได้ผลโหวตเท่ากัน ทั้ง 2 Candidate node ก็จะหยุด Candidate state แล้วรอให้เกิด re-election ใหม่อีกครั้ง
รายละเอียดของกระบวนการ Log Replication
Leader จะมีการส่ง Entry log ไปยังทุกๆ Node และทุกๆ node ก็จะรับ Replication data ไป โดยจะส่งในจังหวะ heartbeat (ส่ง append entry log)
ซึ่งจะมีขั้นตอน ดังนี้
- Client ส่ง Data ไปยัง Leader
- Leader เพิ่มข้อมูลใหม่เข้าสู่ Node’s log
- Leader จะส่ง entry log ใหม่ไปยัง Follower Node
- Follower ตอบรับผลการ Replication
- Leader จะรับผลการ Replication แะส่งผลลัพต์ไปยัง Client ว่าข้อมูลเพิ่มเข้าไปยังระบบเสร็จสมบูรณ์แล้ว
Split Partition System
ในกรณี ที่ระบบถูก Split เป็น 2 Partition กระบวนการในการทำ Log Replication ก็จะยังเหมือนเดิม และเกิดขึ้นแบบเดิมทั้ง 2 Partition และมี 2 Leader ในเวลาเดียวกัน พร้อมกับรับข้อมูลต่างกันจาก 2 Client ได้ โดยถ้ามี Client ที่จะพยายามจะ split ระบบเพื่อจะเพิ่มข้อมูลที่ไม่ถูกต้องลงไปยังระบบ
ระบบจะเข้าสถานะของ Partition ที่มี Node น้อยกว่าให้อยู่ในสถานะ uncommit state ไว้ก่อน (ข้อมูยังเพิ่มไม่เสร็จสมบูรณ์) และจะคงสถานะนั้นไว้ จนกว่าจะเชื่อมทั้งระบบเข้าเป็น partition เดียวกัน และเมื่อเชื่อมต่อระบบเข้าสู่ Partition เดียวกัน ข้อมูลที่ถูก Uncommit อยู่จะถูกทับโดย ข้อมูลที่ Commit แล้วจาก Partition ที่มี Node มากกว่า และจะถือว่า ข้อมูลที่แอบเพิ่มเข้ามาในระบบ ไม่เคยเกิดขึ้นบนระบบเลย
2. Istanbul BFT
ระบบนี้จะใช้หลักการของ BFT (Byzantine Fault Tolerance) มาทำงาน โดยจะให้ทุกๆ node ภายในเครือข่ายร่วมกันโหวต แต่สำหรับ Istanbul BFT จะมีการตั้ง Validator เพื่อมาโหวตภายในเครือข่าย โดยถ้าผลการโหวตมีมากกว่า 2 ใน 3 ของเครือข่าย จะถือว่า block นั้นถูกต้อง และบันทึกลง blockchain
โดยในการติดตั้ง Quorum Blockchain จะสามารถเลือกได้ว่า ต้องการ Consensus แบบไหน เพื่อใช้งาน
ต่อมาเราก็มาดูกันต่อว่าตัว Quorum มีหลักการทำงานอย่างไร
กระบวนการทำงานของ Quorum
ถ้าเป็น Public Transaction ก็จะทำงานเหมือนกับ Ethereum ทั้งหมด พอมีการ submit transaction เข้ามา ก็จะกระจาย transaction ไปให้ทุกโหนด เพื่อหา 1 โหนดในการ confirm transaction ซึ่งข้อมูลภายใน Transaction ทุกโหนดจะสามารถเปิดดูได้ทั้งหมด
แต่ถ้าเป็น Private Transaction จะมีการเพิ่มส่วนการทำงานระหว่าง Ethereum Peer-to-Peer Network และ Constellation Network เข้ามา
โดย Constellation จะแบ่งได้เป็น 2 ส่วนคือ Transaction Manager และ Enclave ตามภาพด้านล่าง
แผนภาพการทำงานของ Private Transaction ระหว่าง Party ที่เชื่อมโยงกันผ่าน Constellation Network
ข้อมูลระหว่าง 2 Party (A และ B) จะมีแค่ A และ B ที่อ่านข้อมูลได้ เพราะ Transaction Manager จะคอยจัดการว่า ใครบ้างที่จะสามารถ Decrypt ข้อมูลได้ ซึ่งทำให้ทุกคนเห็น Transaction Hash แต่จะเปิดอ่านข้อมูลไม่ได้
โดยขั้นตอนการทำงานแบบ Private Transaction มีขั้นตอนดังนี้
- Distribution Application (DApp) ทำหน้าที่ติดต่อ และ รับข้อมูลจาก client มาเพิ่ม หรือ เข้าไปอ่านใน Blockchain
- โดย DApp จะแบ่งแยกระหว่าง Public Transaction และ Private Transaction จะขึ้นอยู่กับ Client
- โดยถ้าเป็นข้อมูลแบบ Public Transaction ข้อมูลจะถูกแชร์กันเลย บน Quorum Node Layer (Public State / Private State ในแผนภาพ)
- แต่ถ้าเป็น Private Transaction ข้อมูลจะถูกส่งไปยัง Transaction Manager หรือ Constellation Network เพื่อเก็บข้อมูล และ เชื่อมโยงว่า Private Transaction นั้นๆ อยู่ใน Constellation Network ใด
- หลังจากเชื่อมต่อ Private Transaction เข้ากับ Transaction Manager บน Network ของ Party นั้นๆแล้ว ก็จะส่งข้อมูลของ Private Transaction นั้นๆ ไปเข้าเข้ารหัส ที่ Enclave ของ Party นั้นๆ
โดยถ้า Constellation Network เดียวกัน จะถือว่า อยู่ Party เดียวกัน และ Transaction Manager จะอนุญาติให้มี Party บน Constellation Network เดียวกัน สามารถเข้าถึงข้อมูล โดยอาศัย Enclave ของ Party นั้นๆ ในการถอดรหัสข้อมูล
สำหรับเบื้องต้นผมก็ขอพูดถึงแค่เท่านี้ก่อนนะครับ กลัวจะยาวเกินไป แล้วในบทความหน้า เราจะมาเริ่มต้นติดตั้งและใช้งานตัว Quorum Blockchain กันครับ รอติดตามนะครับ
จบบทความแล้ว ตรงนี้เป็นส่วนเพิ่มเติม
QuorumChain Consensus
รูปแบบของ consensus ที่ถูกใช้โดยอ้างอิงหลัก time-based และ majority-voting algorithm
ระบบจะมี Voter คอยทำหน้าที่ Vote เพื่อหา Canonical head จาก Canonical Chain
Most Vote = Canonical Chain;
โดย Block Creation จะถูกสร้างโดย Node ทีมี role เป็น Maker (Maker จะทำการ Sign ตัวตน และ เก็บข้อมูลคนที่สร้าง Block ไว้ใน extraData ของ Block Header)
QuorumChain จะมีการเพิ่มส่วน BlockVoting Contract เข้าไปในระบบด้วย เรียกว่า Voting Smart Contract
โดย BlockVoting Contract จะถูก Setup ไว้ที่ตำแหน่ง Genesis Block และจะถูก Pre-Compile Bytecode และปล่อยตัว ABI กลับมาให้ Quorum Client และ function ภายใน BlockVoting Contract จะมี Voters function และ Makers function
ดังนั้น Consensus นี้จะมี Role หลักๆ จะประกอบด้วย
- Voter Node
Node ที่เป็น Voter Node จะต้องมีการ Register ไปยัง BlockVoting Contract เพื่อทำหน้าที่ Vote เพื่อให้เกิด Validity of Block
โดย Voting Role จะมีหน้าที่ Vote ให้กับ Canonical hash ของ Canonical Chain ถ้า Canonical height ไหนได้ Vote มากที่สุด ก็จะเลือก Canonical height นั้นเป็น Canonical Chain
ซึ่ง Voter Node ก็จะต้องถูก Set ใน Pre-config ใน Genesis Block (Genesis json)
และ Vote Node หนึ่งสามารถเพิ่ม หรือ ลบ Voter Node อื่นๆ ได้ โดยการส่ง Transaction ไปยัง function BlockVoting Contract โดย Voter Node จะต้องถูกตั้งและ setup ไว้บน Votethreshold ก่อนจึงจะมีสิทธิ์อยู่บน Chain ในฐานะ Voter ได้
- Maker Node
คอยทำหน้าที่สร้าง Block ใหม่ และ Address ของ Maker Account จะถูกเก็บอยู่บน BlockVoting Contract
** จะต้องมี Maker อย่างน้อย 1 maker บน Contract **
จะต้องมีการ setup initial สำหรับ Maker Node ไว้ด้วยใน Genesis Block เพื่อระบุ Maker Node แรกของระบบ
โดย Maker Node สามารถเพิ่มหรือลบ Maker Node อื่นๆด้วยกันได้ โดยการส่ง Transaction คำสั่งไปยัง function บน BlockVoting Contract
** Maker Node สามารถเป็น Voter Node ได้ **
- Observer Node
เป้น Node ที่ไม่ได้เป็นทั้ง Voter หรือ Maker มีหน้าที่เข้าดูข้อมูลบน chain ส่วนที่สามารถเข้าถึงได้
Block Creation คือ กระบวนการสร้าง Block ใหม่บน Chain
Maker Node จะมีหน้าที่ในการสร้าง Block โดยมีขั้นตอนดังนี้
Maker Node จะ Generate random ระยะเวลามา 1 ชุดและต้องรอจนกว่าจะหมด timeout ของ เวลาที่สุ่มมา จึงจะสร้าง Block ใหม่ โดยจะต้องไม่มี Maker node อื่นสร้าง Block ใหม่ก่อน โดยถ้าได้สร้าง Block ใหม่ในเวลาที่ตั้ง timeout ไว้ จะถือว่า Block นั้นเป็น Block จริง กระบวนการนี้เรียกว่า BlockMakerStrategy
โดยในการสุ่ม timeout จะอยู่ในขอบเขต Min และ Max โดยสามารถ set ได้ใน CLI คือ เข้าไปตั้งค่า — minblocktime และ — maxblocktime เป็น min และ max ของ timeout
และหลังจากสร้าง Block ได้สำเร็จ ก็จะถูกเพิ่มเข้าไปใน head ของ chain (new pending block) และเมื่อเพิ่ม block เข้าไปใหม่ (และทุกๆ Transaction ของการ process ต่างๆ ก็จะถูกเพิ่มเข้าไปใน Block ที่สร้างขึ้นใหม่ และอยู่ในสถานะ pending state ใน new block)
Block Voting คือ กระบวนการ Vote Block ใหม่ ว่า Block นั้นถูกต้อง
ระบบจะสอดคล้องกับ BlockMakerStrategy กระบวนการ Vote จะอยู่ในช่วง period ของ Block Creation โดยหลังจาก Block ถูกสร้างขึ้นใหม่ และ Transaction ถูกเพิ่มแล้ว หลังจากนั้น Voter ก็จะทำหน้าที่ vote ไปยัง block ที่สร้างใหม่นี้ โดยจะติดต่อ vote ผ่าน BlockVoting Contract
รูปแบบของ BlockVoting Contract ในการ Vote
โดยกระบวนการ voting มีดังภาพ
- Maker Node ทำการสร้าง Block ใหม่ (Block 2) โดย block ที่จะสร้างจะบรรจุผล vote เข้าไปด้วย
- Block ที่สร้างใหม่จะถูก publish ไปยัง Network โดยใช้ Standard Ethereum P2P Protocol โดยทุกๆ Node จะรับ Block ไป
- Vote ทำการตรวจสอบ และ Validate Block โดยจะมีการ
- Call ไปยัง BlockVoting Contract เพื่อเช็คว่า Maker คนนี้มีสิทธิ์ สร้าง block ใหม่
- Call ไปยัง BlockVoting Contract เพื่อเช็คว่า Block นั้นๆ มีผล Vote ที่เพียงพอหรือไม่
- ทำการประมวลผล Transaction ใน Block (ทั้งแบบ Public Transaction และ Private Transaction ใน Party Node) ซึ่งส่วนนี้จะมีส่วนของ Transaction manager เข้ามาจัดการ
- Validate the public state โดยการเทียบกับ public state root hash ใน block
- ทำการ hashing all transaction ใน block (Public และ Private) และเทียบ hash กับ Transaction hash บน block
- Successfully validate Voter ทำการส่ง vote ไปยัง BlockVoting contract โดยอาศัย standard ethereum transaction
- Maker Node ที่อยู่ในช่วง timeout และพบ block ใหม่ก็จะย้อนกระบวนการเดิม [Block Creation → Validation → Voting process]
Author : D’Last Wishes
