สวัสดีครับเพื่อนๆ

สำหรับบทความ Zama Part 2 Series ในพาร์ทนี้ เราจะพาผู้อ่านทุกๆท่านมาเรียนรู้การทำงานของ FHEVM บน Zama Ecosystem ในปัจจุบัน สู่การเป็น FHE Developer เพื่อเขียน CSC/Confidential Smart Contract ให้สำเร็จกันครับ

แนะนำบทความ

https://mirror.xyz/lordachita.eth/KHKIWav5pSO7_6yrNlYLG_rVkx8CqIOKYB4q9Sh154I

https://mirror.xyz/lordachita.eth/I0OSH6awQP87o34HjGRlPBPg5ypL6m9Wnqb_4xcL1ZI

หมายเหตุ: บทความดังกล่าว ได้รวบรวมและเรียบเรียงจากเอกสาร documentation ต่างๆจากทาง Zama เพื่อให้ผู้อ่านทำความเข้าใจได้ง่ายยิ่งขึ้น

FHE on blockchain | Protocol

This section explains in depth the Zama Confidential Blockchain Protocol (Zama Protocol) and demonstrates how it can bring encrypted computation to smart contracts using Fully Homomorphic Encryption (FHE). FHEVM is the core technology that powers the Zama Protocol. It is composed of the following key components. Gateway - The central orchestrator of the protocol.

https://docs.zama.ai

FHEVM เป็นเบื้องหลังสำคัญของ Zama Protocol จะประกอบด้วย key components หลักๆดังนี้

1. FHEVM library: เป็นเครื่องมือสำหรับ SC Developer ใช้ในการเขียน CSC

2. Host Contracts : เป็น SC ที่ทำหน้าที่ควบคุมและเรียกใช้การประมวลผล FHE ที่เกิดขึ้นนอกเครือข่าย (off-chain)

3. Coprocessors – เป็นส่วนให้บริการที่ทำหน้าที่ verify ที่ถูกเข้ารหัสไว้ (encrypted data), รันการประมวลผลแบบ FHE และทำหน้าที่ส่งผลลัพธ์ที่ได้กลับไปยังระบบ

4. Gateway – เป็นตัวกลางหลักที่ประสานการทำงานต่างๆภายใน Zama Protocol ได้แก่ การ validate encrypted data, การควบคุมสิทธิ์การเข้าถึง/Access Control Lists (ACLs), จัดการการส่งข้อมูลที่เข้ารหัส (cyphertexts) ไปมาระหว่าง blockchain (bridge) และการทำงานประสานงานกันกับ 3. Coprocessors และ 5. KMS

5. Key Management Service (KMS) – เป็นเครือข่ายแบบ threshold MPC ที่ช่วยสร้าง และจัดการเรื่องของการหมุนเวียนกุญแจ FHE รวมถึงการจัดการ decryption ให้มีความปลอดภัยและสามารถตรวจสอบได้

ผู้เขียนแนะนำให้ผู้อ่านทบทวน workflow ที่แนบไว้พร้อมอ่านประกอบคำอธิบายประมาณ 5 นาที ก่อนที่จะไปกันต่อครับ

หมายเหตุ: การอธิบายความแตกต่างระหว่างการ verify และ validate ให้เห็นภาพชัดๆ จะไม่ได้อยู่ใน scope ของบทความนี้ เพราะมีดีเทลที่ต้องอธิบายอยู่พอสมควร สำหรับผู้อ่านทั่วๆไป สามารถแปลได้เลยว่า เป็นการตรวจสอบความถูกต้องแค่คนละบริบทกัน

ในส่วนนี้ เราจะมาอธิบายกันถึงรายละเอียดแต่ละ key components ของ FHEVM กันครับ

ผู้เขียนขอยก 3 ตัวอย่าง key features ที่ library นี้สามารถขยายต่อการทำงานของ Solidity library ได้ให้เห็นภาพ

1. สามารถกำหนดประเภทของข้อมูล encrypted data ได้ เช่น

• Booleans: ebool

• Unsigned integers: euint8, euint16, ..., euint256

• Signed integers: eint8, eint16, ..., eint256

• Addresses: eaddress

2. สามารถคำนวณทางคณิตศาสตร์บน encrypted types ได้ เช่น

• Arithmetic: add, sub, mul, div, rem, neg

• Logic: and, or, xor, not

• Comparison: lt, gt, le, ge, eq, ne, min, max

• Bit manipulation: shl, shr, rotl, rotr

3. สามารถจัดการ Access Control ได้

โดยมี method สำหรับจัดการ access เพื่อเข้าถึง encrypted values ผ่านการใช้ ACL/Access Control List บน 2. Host Contracts:

• allow(handle, address): Grant persistent access

• allowTransient(handle, address): Grant access สำหรับเฉพาะ transaction ที่กำลังเกิดขึ้น

• allowForDecryption(handle): Make handle publicly decryptable

• isAllowed(handle, address): ตรวจสอบว่า address นั้นมี access

• isSenderAllowed(handle): Shortcut สำหรับการตรวจสอบ msg.sender permissions

พวกเราจะมาลงดีเทลกันในบทความถัดๆไป

หมายเหตุ: handle = encrypted data

Host Contracts (Trusted SC บน EVM/non-EVM Blockchains) ทำหน้าที่เป็นผู้รักษาความปลอดภัยบน on-chain ทำหน้าที่เชื่อมต่อระหว่าง on-chain Apps กับ FHEVM โดยเป็น interface ที่ CSC ใช้สำหรับ

• ติดต่อสื่อสารกับ encrypted data

• ทำ access control ต่างๆเช่น การกำหนด users/SC ที่ได้รับอนุญาตให้ใช้งาน/decrypt handle/encrypted data ได้

• ส่ง events ต่างๆที่เกิดขึ้นไปยัง off-chain components (3. Coprocessors, 4. Gateway)

Coprocessor เป็น decentralize compute layer ที่ทำหน้าที่คำนวณงานประเภท cryptography ที่มีซับซ้อนโดยเฉพาะการคำนวณ FHE แทน SC อีกทั้งเป็นตัวประสานตรรกะการทำงานบน on-chain ให้เข้ากับการทำงานของ encryption ได้แก่

1. การคอยฟัง events ที่ส่งมาจาก Host Chain และ 4. Gateway

2. Encrypted Input Verification - เมื่อผู้ใช้งานส่ง encrypted data เข้ามาที่ Gateway แต่ละ Coprocessor จะทำการตรวจสอบความถูกต้องของ encryped input และ ZK Proofs of Correctness ที่เกี่ยวข้อง จากนั้นจึงทำการ extracts, unpacks แต่ละ ciphertexts ออกจาก submission ที่รวมกันมา แล้วเก็บ ciphertexts ภายใต้ handles ที่ได้รับ แล้วทำการ sign ตัว handles ที่ถูก verified แล้วรวมถึงฝัง metadata ของผู้ใช้งานและ SC และสุดท้ายจึงทำการส่งข้อมูลที่ signed แล้วกลับไปที่ Gateway เพื่อทำประชามติ (consensus)

3. FHE Computation Execution - เมื่อ SC ทำงานบนข้อมูลที่เข้ารหัส ระบบ on-chain logic จะส่ง symbolic computation events ไปยัง Coprocessors ซึ่งจะอ่าน events เหล่านี้จาก Host Chain Node และดึง ciphertext ที่เกี่ยวข้องจาก storage มาดำเนินการ FHE operations โดยใช้ TFHE-rs library จากนั้นเก็บผลลัพธ์ภายใต้ handle ที่ได้แบบ deterministically และอาจเผยแพร่ commitment (digest) ของ ciphertext ไปยัง Gateway เพื่อตรวจสอบได้ ซึ่งกระบวนการเหล่านี้จะช่วยลดภาระ computation ของ host chain พร้อมรักษาความเป็น determinism นอกจากนี้ เพื่อเป็นการป้องกันการทุจริต แต่ละ coprocessor ต้อง commit ciphertext digest (ผ่าน hash) เมื่อประมวลผล Allowed events และ publish commitment เหล่านั้นไปยัง Gateway เพื่อเปิดให้มีการตรวจสอบ FHE computation จากภายนอก และใช้เป็นหลักฐานในการลงโทษ (slashing) operator ที่ทุจริตหรือทำงานผิดพลาด

4. ACL Replication - Coprocessors จะคอยจัดการและอัปเดตแบบจำลองของ Access ผ่านการทำซ้ำ Access Control List (ACL) จาก Host Contracts จากการฟัง events ในส่วนของ Allowed และ AllowedForDecryption แล้วจึงทำการส่ง (push) updates ไปยัง Gateway ทำให้สามารถที่จะคุมสิทธิการเข้าถึงได้แบบ decentralized

5. Bridging & Decryption Support - Coprocessors ทำหน้าที่จัดเก็บและให้บริการ encrypted data สำหรับการ bridge และ decryption ในฝั่งของการ bridge encrypted data ระหว่าง Host Chain จะใช้วิธีสร้าง handles และ signatures ใหม่ และสำหรับ public/user decryption นั้น Coprocessor มีการทำ normalize ciphertexts ก่อนส่งข้อมูลไปยัง KMS

อย่างไรก็ตาม Zama protocol จะมีสมมติที่ว่า ตราบใด Coprocessors มากกว่าครึ่งหนึ่งทำงานแบบซื่อสัตย์ ผลลัพธ์ที่ได้จะถือว่าถูกต้อง เมื่อ Coprocessors ส่งผลลัพธ์ไปยัง Gateway แล้ว Gateway จะรวบรวมและตัดสินใจเลือก output สุดท้ายก็ต่อเมื่อได้ข้อสรุปจากเสียงข้างมากแล้ว (majority consensus) และเพื่อเป็นการป้องกันการทุจริต Coprocessors จะต้อง stake เหรียญ $ZAMA โดยหากตรวจการทุจริต จะถูกลงโทษผ่านการ slashing ไม่ว่าจะผ่านการตรวจสอบแบบอัตโนมัติ หรือ การผ่านกลไก governance

เป็นส่วนประกอบเฉพาะของ blockchain ที่ถูกสร้างขึ้นมาแบบ trust-minimized (ปัจจุบันถูก implemented ในรูปแบบของ Arbitrum Rollup) โดยทำหน้าที่หลักในการประสาน/orchestrate งานและยืนยันความถูกต้องของงานต่างๆ ดังต่อไปนี้

1. Encrypted Input Validation - Gateway จะยืนยันข้อมูลจากผู้ใช้งานที่ถูก encrypted ไว้ร่วมกับ Zero-Knowledge Proofs of Knowledge แล้วจึงทำการส่ง verification events ไปยัง coprocessors เพื่อทำการตรวจสอบ จากนั้นจึงรวบรวม signatures ที่ได้จาก coprocessors กลุ่มส่วนมาก เพื่อสร้าง Attestations (การรับรอง) ซึ่งสามารถนำไปใช้งานต่อบน on-chain ได้

2. Cross-chain Ciphertext Bridging - Gateway สามารถจัดการเรื่องการ bridge encrypted handles ระหว่าง Host Chains โดยทำการตรวจสอบสิทธิ์การเข้าถึงบน source chain ผ่านการใช้สำเนาของ ACL จากนั้นจึงทำ requests ไปให้ coprocessors เพื่อทำการคำนวณ handles ใหม่ๆสำหรับ target chain แล้วจึงรวบรวม signatures ที่ได้จาก coprocessors

3. Decryption Orchestration - เมื่อผู้ใช้งาน/SC ส่งคำร้องขอ decryption ตัว Gateway จะทำการตรวจสอบ ACL permissions เพื่อที่จะสั่งให้ KMS ทำการ decrypt (ทั้งกรณี public และ private) และเมื่อ KMS ส่งผลลัพธ์ที่ถูก signed แล้วคืน ตัว Gateway จะส่ง events ทั้งรูปแบบที่ Oracle สามารถเก็บไว้ (สำหรับ SC ทำ decryption) หรือในรูปแบบที่ส่งไปยังผู้ใช้งานได้เช่นกัน (สำหรับการทำ private decryption)

4. Consensus/Slashing Enforcement - ในกรณีที่มีการไม่ลงรอยกันระหว่าง coprocessors และ KMS Node พฤติกรรมการทุจริตหรือผิดพลาดอาจโดนสอบทานและนำไปสู่การ slashed และอาจทำให้ระบบ governance ทำงานเพื่อตรวจสอบผ่าน off-chain หากจำเป็น

5. Staking/Reward Distribution - สำหรับ Operators ที่เข้าร่วมการทำ FHE computations.

6. Access Control Coordination - Gateway จะเก็บ copy ของ ACLs จาก Host Chains เพื่อที่จะตัดสินใจว่าสามารถที่จะทำ decryption, computation บน ciphertext ได้หรือไม่ โดยการ updates ของ ACL จะถูกทำซ้ำและส่งไปยัง Gateway สำหรับการ verification/enforcement

7. Protocol Administration - Gateway จะใช้งาน SC ที่สามารถจัดการเรื่องของ การลงทะเบียน Operator และ Participant (Coprocessors, KMS Nodes, Host Chains) การทำ Key Management, การเชื่อมต่อ Logic, การตรวจสอบข้อมูลฝั่งขาเข้าและขั้นตอนการทำงานของการถอดรหัส

KMS เป็น Decentralized Network ของ Nodes/Parties ต่างๆ ที่ทำงานร่วมกันผ่าน MPC (Multi-Party Computation) Protocol มีหน้าที่หลักดังนี้

1. FHE threshold key generation - KMS จะสร้าง global public/private key pair อย่างปลอดภัย ซึ่งสามารถนำไปใช้ร่วมกันได้ในทุก Host Chain ในส่วนของ private key จะไม่มีทางเข้าถึงได้โดยตรงจากฝ่ายใดฝ่ายหนึ่ง แต่จะถูกแบ่งแบบลับระหว่าง MPC Nodes ระบบการสร้างกุญแจนี้จะเป็นไปตามมาตรฐาน NIST SP 800-57 Key Lifecycle Model สำหรับการจัดการ key states ต่างๆเช่น Active, Suspended, Deactivated และ Destroyed เพื่อให้มั่นใจว่าระบบมีความปลอดภัยและรองรับการเปลี่ยนกุญแจอย่างเหมาะสม

2. Threshold Decryption via MPC - KMS จะทำการ decryption โดยใช้ Threshold Decryption Protocol ซึ่งระบุว่าจะต้องมีจำนวนขั้นต่ำของ MPC parties (เช่น 9 จาก 13) เข้าร่วมในการถอดรหัสด้วยกลไกนี้ จะไม่มีโหนดใดเพียงลำพังที่สามารถเข้าถึงกุญแจทั้งหมดได้ และจำเป็นต้องมีจำนวนโหนดที่มากกว่า threshold ของ KMS Nodes จึงจะสามารถควบคุมระบบได้ ในส่วนของการติดต่อสื่อสารระหว่าง nodes จะถูกรักษาความปลอดภัยด้วย mTLS กับ gRPC โดยในส่วนของ protocol จะมีการรองรับการทำ Public Decryption สำหรับ SC และ User Decryption สุดท้ายผลลัพธ์ที่ได้จากการทำ decryption จะถูก signed โดยแต่ละ node และสามารถที่จะถูก verified ผ่าน on-chain

3. ZK Proof Support - KMS จะทำการสร้าง Common Reference Strings (CRS) สำหรับการยืนยันความถูกต้องของ Zero-Knowledge Proofs of Knowledge (ZKPoK) เมื่อผู้ใช้ส่งข้อมูลที่ถูกเข้ารหัสเข้ามา ระบบจะสามารถ ยืนยันได้ว่าข้อมูลนั้นมีความถูกต้องและเป็นไปตามรูปแบบที่กำหนดรวมถึงยืนยันได้ว่า ผู้ใช้มีความรู้จริงเกี่ยวกับ plaintext ที่อยู่ภายใน ciphertext ที่ส่งมา

นอกจากนั้น KMS ยังมีระบบ Custodial Backup ซึ่งแต่ละ MPC Nodes จะทำการแบ่ง key ออกเป็น encrypted fragments แล้วกระจายไปยัง ผู้ดูแล/custodians ในกรณีที่โหนด MPC บางส่วนออฟไลน์ กลุ่มผู้ดูแลก็ยังสามารถร่วมกันกู้คืนกุญแจได้อย่างปลอดภัย แม้ระบบจะเกิดปัญหา/outages) ก็ยังสามารถทำงานต่อได้ อีกทั้งกระบวนการกู้คืนยังสามารถที่จะตรวจสอบได้ผ่าน on-chain

Oracles และ Relayers เป็นจุดเชื่อมต่อที่สำคัญระหว่างผู้ใช้งาน, SC และ off-chain infrastructure บน Zama Protocol โดยทั้งสองทำหน้าที่เป็น lightweight services ที่โต้ตอบกับ Gateway ซึ่งช่วยให้ผู้ใช้งานและ SC ไม่ต้องจัดการกับกลไกการทำงานที่ซับซ้อนโดยตรง จึงสามารถผสานการประมวลผลแบบ encryption เข้ากับการใช้งานของแอปพลิเคชันได้อย่างราบรื่น โดยไม่ต้องแลกกับความปลอดภัยหรือการกระจายศูนย์

• ฝั่ง SC จะใช้ Oracle เพื่อรับผลลัพธ์ในรูปแบบ plaintext จากการคำนวณแบบ encrypted ผ่าน callbacks.

• ฝั่งผู้ใช้งานจะใช้ Relayer สำหรับส่งข้อมูลที่ถูก encrypted ไปยังตัวระบบและดึงข้อมูลที่ถูก decrypted ผ่าน EIP-712 signatures และ FHE key re-encryption

โดย Oracles เป็น off-chain services ที่ทำหน้าที่ดึงข้อมูลที่ถูก decrypted จาก FHEVM

1. รอคำขอ on-chain decryption จาก SC

2. ทำการส่งคำขอ decryption ไปยัง Gateway ในฐานะตัวแทน SC

3. รอ KMS ส่ง plaintexts ที่ถูก signed ผ่าน Gateway

4. Call back SC บน Host Chain พร้อมส่งผลลัพธ์ที่ถูก decrypted

ระบบจึงได้ Oracles ที่มีความ trustless และผลลัพธ์ที่ได้มาถูก signed และ verifiable บน on-chain ในกรณีที่มี Oracle ที่ไม่สามารถทำงาน ณ ขณะนั้นได้ จะมี Oracle อื่นๆที่สามารถมาทำงานแทนได้ จึงทำให้ SC สามารถที่จะเขาถึงข้อมูลที่ถูก decrypted ได้แบบพร้อมๆกันและมีความปลอดภัย

ในส่วนของ Relayer จะเป็นส่วนที่ให้บริการผู้ใช้งานเพื่อทำงานกับ Gateway โดยเฉพาะเรื่องของการคำนวณ encryption และ decryption ที่ต้องทำผ่าน off-chain ได้สะดวกสบายขึ้น โดย

1. user ส่ง encrypted inputs ไปยัง Gateway เพื่อทำการลงทะเบียน

2. ดำเนินการคำขอ decryption จากฝั่งผู้ใช้งาน รวมถึงการทำ EIP-712 authentication

3. รวบรวมผลลัพธ์จาก KMS และทำการ re-encrypted โดยใช้ public key ของผู้ใช้งาน

4. นำ ciphertext ส่งหลับไปที่ user และถูก decrypts ภายใต้ App/Browser

ทำให้ users สามารถที่จะใช้งาน CSC โดยไม่จำเป็นต้องทำ interface, validator, รวมถึง FHE tooling ของ Gateway ด้วยตัวเอง

1. Dev เพิ่ม Library → เขียน “กล่องลับ Smart Contract”
   นักพัฒนาใช้ FHEVM Library SC พิเศษที่สามารถประมวลผลข้อมูลที่เข้ารหัสได้ เปรียบเสมือน "กล่องลับ" ที่เก็บข้อมูลไว้เป็นส่วนตัว ไม่ให้ใครเห็นเนื้อหาจริง ๆ

2. User ใส่ข้อมูลลงกล่อง → ส่งผ่าน Relayer → Gateway
   ผู้ใช้จะใส่ข้อมูลที่ต้องการประมวลผลลงใน "กล่องลับ" ที่เข้ารหัสไว้ จากนั้น Relayer ซึ่งเป็นบริการขนาดเล็กจะช่วยส่งคำขอเข้ารหัสนี้ไปยัง Gateway และ Relayer ทำให้กระบวนการนี้ง่ายขึ้นสำหรับผู้ใช้ โดยไม่ต้องจัดการกับความซับซ้อนเบื้องหลังเอง.

3. Gateway ยืนยัน + แจกงานให้ Coprocessors
   Gateway ทำหน้าที่เป็นตัวกลางหลักในการรับและตรวจสอบข้อมูลที่เข้ารหัสจากผู้ใช้ หลังจากยืนยันความถูกต้องแล้ว Gateway จะมอบหมายงานการประมวลผลข้อมูลที่เข้ารหัสเหล่านี้ให้กับ Coprocessors

4. Coprocessors คำนวณบนกล่องทึบ → ส่งผล+ลายเซ็นคืน
   Coprocessors เป็นส่วนที่รับผิดชอบการคำนวณทางคณิตศาสตร์ที่ซับซ้อนบนข้อมูลที่ยังคงเข้ารหัสอยู่ โดยที่พวกเขาไม่เห็นข้อมูลจริงๆ พวกเขาจะทำการตรวจสอบความถูกต้องของข้อมูลที่เข้ารหัสและดำเนินการคำนวณ FHE เมื่อเสร็จสิ้น Coprocessors จะส่งผลลัพธ์พร้อมลายเซ็นกลับไปยัง Gateway เพื่อให้มีการตรวจสอบ

5. ถ้าต้องเปิดกล่อง → Gateway เรียก KMS ถอด → ส่งผลผ่าน Oracle/Relayer
   หากจำเป็นต้องถอดรหัสข้อมูลหรือผลลัพธ์ Gateway จะส่งคำขอไปยัง Key Management Service (KMS) ซึ่งเป็นเครือข่ายแบบกระจายศูนย์ จะทำการถอดรหัสข้อมูลอย่างปลอดภัย ผลลัพธ์ที่ถอดรหัสแล้วจะถูกส่งกลับผ่าน Oracle สำหรับ Smart Contract หรือ Relayer สำหรับผู้ใช้งาน

เพียงเท่านี้ บล็อกเชนก็สามารถ “คิดเลขให้เรา โดยที่มันไม่เคยเห็นเลขจริงเลย”

o3-pro & Gemini 2.5, 2025

1. NIST SP 800-57 - eips.ethereum.org/EIPS/eip-712

2. EIP-712 - csrc.nist.gov/pubs/sp/800/57/pt1/r5/final