บทความต้นฉบับโดย @Web3_Mario
ฉันกำลังมองหาแนวทางใหม่สำหรับโครงการนี้ เมื่อทำการออกแบบผลิตภัณฑ์ ฉันได้พบกับเทคโนโลยีที่ไม่เคยพบมาก่อน ฉันจึงค้นคว้าข้อมูลและรวบรวมประสบการณ์การเรียนรู้เพื่อแบ่งปันกับคุณ โดยทั่วไป zkTLS เป็นเทคโนโลยีใหม่ที่ผสมผสานระหว่าง zero-knowledge proof (ZKP) และ TLS (Transport Layer Security Protocol) ในแทร็ก Web3 จะใช้ในสภาพแวดล้อมเครื่องเสมือนแบบออนเชนเป็นหลัก สามารถตรวจสอบความถูกต้องของข้อมูล HTTPS นอกเชนที่จัดเตรียมไว้โดย zkTLS ได้โดยไม่ต้องเชื่อถือบุคคลที่สาม ความถูกต้องในที่นี้ประกอบด้วยสามประเด็น: แหล่งที่มาของข้อมูลมาจากทรัพยากร HTTPS บางอย่าง ข้อมูลที่ส่งกลับมาไม่ได้ถูกดัดแปลง และสามารถรับประกันความถูกต้องของข้อมูลได้ ด้วยกลไกการใช้งานการเข้ารหัสนี้ สัญญาอัจฉริยะแบบออนเชนจะสามารถเข้าถึงทรัพยากร Web2 HTTPS นอกเชนได้อย่างน่าเชื่อถือ และทำลายไซโลข้อมูลลงได้
โปรโตคอล TLS คืออะไร?
เพื่อให้เข้าใจถึงคุณค่าของเทคโนโลยี zkTLS ได้ลึกซึ้งยิ่งขึ้น จำเป็นต้องให้ภาพรวมสั้นๆ เกี่ยวกับโปรโตคอล TLS ประการแรก TLS (Transport Layer Security) ใช้สำหรับการเข้ารหัส การตรวจสอบสิทธิ์ และความสมบูรณ์ของข้อมูลในการสื่อสารเครือข่าย ช่วยให้มั่นใจถึงการส่งข้อมูลที่ปลอดภัยระหว่างไคลเอนต์ (เช่น เบราว์เซอร์) และเซิร์ฟเวอร์ (เช่น เว็บไซต์) สำหรับผู้ที่ไม่ได้สนใจเรื่องการพัฒนาเครือข่าย คุณอาจพบว่าเมื่อเข้าชมเว็บไซต์ ชื่อโดเมนบางชื่อจะมี https นำหน้า และบางชื่อจะมี http นำหน้า เมื่อเข้าถึงส่วนหลังนี้ เบราว์เซอร์หลักจะแจ้งว่าไม่ปลอดภัย แบบแรกมีแนวโน้มที่จะประสบกับข้อความแจ้งเตือนเช่น ลิงก์ของคุณไม่ใช่ลิงก์ส่วนตัว หรือข้อผิดพลาดเกี่ยวกับใบรับรอง HTTPS มากกว่า เหตุผลของการแจ้งเตือนนี้เป็นเพราะความพร้อมใช้งานของโปรโตคอล TLS
โดยเฉพาะอย่างยิ่งโปรโตคอลที่เรียกว่า HTTPS นั้นใช้โปรโตคอล TLS บนพื้นฐานของโปรโตคอล HTTP เพื่อให้แน่ใจถึงความเป็นส่วนตัวและความสมบูรณ์ของการส่งข้อมูล และทำให้สามารถตรวจสอบความถูกต้องของเซิร์ฟเวอร์ได้ อย่างที่ทราบกันดีว่า HTTP เป็นโปรโตคอลเครือข่ายที่ส่งข้อมูลในรูปแบบข้อความธรรมดา และไม่สามารถตรวจสอบความถูกต้องของเซิร์ฟเวอร์ได้ ส่งผลให้เกิดปัญหาความปลอดภัยหลายประการ:
1. ข้อมูลที่ส่งระหว่างคุณและเซิร์ฟเวอร์อาจถูกตรวจสอบโดยบุคคลที่สาม ส่งผลให้เกิดการรั่วไหลของความเป็นส่วนตัว
2. คุณไม่สามารถตรวจสอบความถูกต้องของเซิร์ฟเวอร์ได้ นั่นคือตรวจสอบว่าคำขอของคุณถูกแฮ็กโดยโหนดที่เป็นอันตรายอื่น ๆ และส่งกลับข้อมูลที่เป็นอันตรายหรือไม่
3. คุณไม่สามารถตรวจสอบความสมบูรณ์ของข้อมูลที่ส่งกลับมาได้ เช่น การสูญเสียข้อมูลอาจเกิดขึ้นเนื่องจากปัญหาเครือข่ายหรือไม่
โปรโตคอล TLS ได้รับการออกแบบมาเพื่อแก้ไขปัญหาเหล่านี้ ให้ฉันอธิบายตรงนี้ บางคนอาจรู้จักโปรโตคอล SSL จริงๆ แล้วโปรโตคอล TLS ได้รับการพัฒนาขึ้นจาก SSL เวอร์ชัน 3.1 เพียงแต่เปลี่ยนชื่อเนื่องจากปัญหาที่เกี่ยวข้องกับธุรกิจ แต่จริงๆ แล้วโปรโตคอล TLS ก็เป็นโปรโตคอลเดียวกัน ดังนั้นบางครั้งในบางบริบท คำทั้งสองคำอาจใช้แทนกันได้
แนวคิดหลักของโปรโตคอล TLS ในการแก้ไขปัญหาข้างต้นคือ:
1. การสื่อสารแบบเข้ารหัส: ใช้การเข้ารหัสแบบสมมาตร (AES, ChaCha 20) เพื่อปกป้องข้อมูลและป้องกันการดักฟัง
2. การพิสูจน์ตัวตน: ใช้ใบรับรองดิจิทัล (เช่น ใบรับรอง X.509) ที่ออกโดยบุคคลภายนอกให้กับองค์กรที่กำหนดเพื่อยืนยันตัวตนของเซิร์ฟเวอร์และป้องกันการโจมตีแบบ man-in-the-middle (MITM)
3. ความสมบูรณ์ของข้อมูล: ใช้ HMAC (รหัสยืนยันข้อความแฮช) หรือ AEAD (การเข้ารหัสที่รับรอง) เพื่อให้มั่นใจว่าข้อมูลจะไม่ถูกดัดแปลง
มาอธิบายรายละเอียดทางเทคนิคของโปรโตคอล HTTPS ที่ใช้โปรโตคอล TLS ในกระบวนการโต้ตอบข้อมูลโดยย่อกัน กระบวนการทั้งหมดแบ่งออกเป็น 2 ขั้นตอน ขั้นตอนแรกคือขั้นตอนการจับมือ ซึ่งก็คือ ไคลเอนต์และเซิร์ฟเวอร์จะเจรจาพารามิเตอร์ความปลอดภัยและสร้างเซสชันที่เข้ารหัส ประการที่สองคือขั้นตอนการส่งข้อมูล ซึ่งใช้คีย์เซสชันในการสื่อสารแบบเข้ารหัส กระบวนการเฉพาะแบ่งออกเป็นสี่ขั้นตอน:
1. ไคลเอนต์ส่ง ClientHello:
ไคลเอนต์ (เช่นเบราว์เซอร์) ส่งข้อความ ClientHello ไปยังเซิร์ฟเวอร์ ซึ่งประกอบด้วย:
เวอร์ชัน TLS ที่รองรับ (เช่น TLS 1.3)
อัลกอริทึมการเข้ารหัสที่รองรับ (ชุดรหัส เช่น AES-GCM, ChaCha 20)
ไคลเอนต์แบบสุ่ม (ใช้สำหรับการสร้างคีย์)
พารามิเตอร์การแบ่งปันคีย์ (เช่นคีย์สาธารณะ ECDHE)
SNI (การระบุชื่อเซิร์ฟเวอร์) (ทางเลือก ใช้เพื่อรองรับชื่อโดเมนหลายชื่อใน HTTPS)
วัตถุประสงค์คือเพื่อให้เซิร์ฟเวอร์ทราบถึงความสามารถในการเข้ารหัสของไคลเอนต์และเตรียมพารามิเตอร์การรักษาความปลอดภัย
2. เซิร์ฟเวอร์จะส่ง ServerHello:
เซิร์ฟเวอร์ตอบกลับด้วยข้อความ ServerHello ซึ่งประกอบด้วย:
อัลกอริทึมการเข้ารหัสที่เลือก
เซิฟเวอร์สุ่ม
ใบรับรองของเซิร์ฟเวอร์ (ใบรับรอง X.509)
พารามิเตอร์การแชร์คีย์ของเซิร์ฟเวอร์ (เช่นคีย์สาธารณะ ECDHE)
ข้อความเสร็จสิ้น (ใช้เพื่อยืนยันว่าการจับมือเสร็จสมบูรณ์)
วัตถุประสงค์คือเพื่อแจ้งให้ไคลเอนต์ทราบถึงตัวตนของเซิร์ฟเวอร์และยืนยันพารามิเตอร์ความปลอดภัย
3. ไคลเอนต์ตรวจสอบความถูกต้องของเซิร์ฟเวอร์:
ลูกค้าทำสิ่งต่อไปนี้:
ตรวจสอบใบรับรองเซิร์ฟเวอร์: ต้องแน่ใจว่าใบรับรองนั้นออกโดย CA (ผู้มีอำนาจออกใบรับรอง) ที่เชื่อถือได้ และตรวจสอบว่าใบรับรองนั้นหมดอายุหรือถูกเพิกถอนหรือไม่
คำนวณคีย์ที่ใช้ร่วมกัน: ใช้คีย์สาธารณะ ECDHE ของคุณและของเซิร์ฟเวอร์เพื่อคำนวณคีย์เซสชันซึ่งใช้สำหรับการเข้ารหัสแบบสมมาตร (เช่น AES-GCM) สำหรับการสื่อสารครั้งต่อไป
ส่งข้อความเสร็จสิ้น: พิสูจน์ความสมบูรณ์ของข้อมูลการจับมือและป้องกันการโจมตีแบบ man-in-the-middle (MITM)
จุดประสงค์คือเพื่อให้แน่ใจว่าเซิร์ฟเวอร์เชื่อถือได้และสร้างคีย์เซสชัน
4. เริ่มการสื่อสารแบบเข้ารหัส:
ขณะนี้ไคลเอนต์และเซิร์ฟเวอร์กำลังสื่อสารกันแบบเข้ารหัสโดยใช้คีย์เซสชันที่ตกลงกันไว้
การเข้ารหัสแบบสมมาตร (เช่น AES-GCM, ChaCha 20) ใช้ในการเข้ารหัสข้อมูลเพื่อเพิ่มความเร็วและความปลอดภัย
การปกป้องความสมบูรณ์ของข้อมูล: ใช้ AEAD (เช่น AES-GCM) เพื่อป้องกันการปลอมแปลง
ดังนั้น หลังจากสี่ขั้นตอนเหล่านี้ ปัญหาโปรโตคอล HTTP ก็สามารถแก้ไขได้อย่างมีประสิทธิภาพ อย่างไรก็ตาม เทคโนโลยีพื้นฐานนี้ซึ่งใช้กันอย่างแพร่หลายในเครือข่าย Web2 ได้ก่อให้เกิดปัญหาในการพัฒนาแอปพลิเคชัน Web3 โดยเฉพาะอย่างยิ่งเมื่อสัญญาอัจฉริยะแบบออนเชนต้องการเข้าถึงข้อมูลนอกเชนบางส่วน เนื่องจากปัญหาความพร้อมใช้งานของข้อมูล เครื่องเสมือนแบบออนเชนจะไม่เปิดความสามารถในการเรียกข้อมูลภายนอกเพื่อให้แน่ใจว่าสามารถติดตามข้อมูลทั้งหมดได้ จึงรับประกันความปลอดภัยของกลไกฉันทามติ
อย่างไรก็ตาม หลังจากทำซ้ำหลายครั้ง นักพัฒนาก็พบว่า DApp ยังคงมีความต้องการข้อมูลนอกเครือข่าย จึงเกิดโปรเจกต์ Oracle หลายตัว เช่น Chainlink และ Pyth พวกเขาทำลายปรากฏการณ์ข้อมูลแยกส่วนนี้ด้วยการทำหน้าที่เป็นสะพานเชื่อมระหว่างข้อมูลบนเครือข่ายและข้อมูลนอกเครือข่าย ในเวลาเดียวกันเพื่อให้มั่นใจถึงความพร้อมใช้งานของข้อมูลรีเลย์ Oracle เหล่านี้มักจะถูกนำไปใช้ผ่านกลไกฉันทามติ PoS นั่นคือ ค่าใช้จ่ายของพฤติกรรมที่เป็นอันตรายของโหนดรีเลย์จะสูงกว่าประโยชน์ ดังนั้นจึงจะไม่ให้ข้อมูลที่ผิดพลาดแก่โซ่จากมุมมองทางเศรษฐกิจ ตัวอย่างเช่น หากเราต้องการเข้าถึงราคาถ่วงน้ำหนักของ BTC บนการแลกเปลี่ยนแบบรวมศูนย์เช่น Binance และ Coinbase ในสัญญาอัจฉริยะ เราจำเป็นต้องอาศัย Oracle เหล่านี้เพื่อเข้าถึงและรวบรวมข้อมูลนอกเครือข่ายและโอนไปยังสัญญาอัจฉริยะบนเครือข่ายเพื่อจัดเก็บก่อนที่เราจะสามารถใช้งานได้
zkTLS ช่วยแก้ปัญหาด้านใดบ้าง?
อย่างไรก็ตาม ผู้คนพบว่าโซลูชันการรวบรวมข้อมูลที่ใช้ Oracle นี้มีปัญหาสองประการ:
1. ต้นทุนที่สูงเกินไป: เราทราบดีว่าเพื่อให้มั่นใจว่าข้อมูลที่ส่งโดย Oracle ไปยังเครือข่ายเป็นของแท้และไม่ถูกดัดแปลง จำเป็นต้องมีกลไกฉันทามติ PoS อย่างไรก็ตาม ความปลอดภัยของกลไกฉันทามติ PoS ขึ้นอยู่กับจำนวนเงินที่รับปากไว้ ซึ่งทำให้ต้องเสียค่าใช้จ่ายในการบำรุงรักษา ยิ่งไปกว่านั้น โดยทั่วไปแล้วจะมีการซ้ำซ้อนของการโต้ตอบข้อมูลในกลไกฉันทามติ PoS มาก เนื่องจากชุดข้อมูลจำเป็นต้องถูกส่ง คำนวณ และสรุปซ้ำๆ ในเครือข่าย ก่อนที่จะผ่านฉันทามติได้ ซึ่งจะเพิ่มต้นทุนการใช้ข้อมูลอีกด้วย โดยปกติแล้ว เพื่อดึงดูดลูกค้า โปรเจกต์ของ Oracle จะรักษาเฉพาะข้อมูลหลักบางส่วนให้ฟรี เช่น ราคาของสินทรัพย์หลักอย่าง BTC สำหรับความต้องการพิเศษ คุณต้องจ่ายเงินสำหรับมัน นี่เป็นอุปสรรคต่อนวัตกรรมการใช้งาน โดยเฉพาะความต้องการแบบหางยาวที่กำหนดเอง
2. ประสิทธิภาพต่ำเกินไป: โดยทั่วไปแล้ว การบรรลุฉันทามติของกลไก PoS ต้องใช้เวลาพอสมควร ซึ่งทำให้ข้อมูลบนเชนเกิดความล่าช้า ซึ่งไม่เอื้อต่อสถานการณ์การเข้าถึงความถี่สูงบางสถานการณ์ เนื่องจากมีความล่าช้าระหว่างข้อมูลที่ได้รับบนเชนและข้อมูลนอกเชนจริง
เพื่อแก้ไขปัญหาข้างต้น เทคโนโลยี zkTLS จึงถือกำเนิดขึ้น แนวคิดหลักคือการแนะนำอัลกอริทึม ZKP Zero-Knowledge Proof เพื่อให้สัญญาอัจฉริยะแบบออนเชนสามารถทำหน้าที่เป็นบุคคลที่สามเพื่อตรวจสอบโดยตรงว่าข้อมูลที่โหนดให้มานั้นเป็นข้อมูลที่ส่งกลับมาหลังจากเข้าถึงทรัพยากร HTTPS บางอย่างและไม่ได้ถูกดัดแปลง ซึ่งสามารถหลีกเลี่ยงต้นทุนการใช้งาน Oracle แบบดั้งเดิมที่สูงซึ่งเกิดจากอัลกอริทึมฉันทามติได้
เพื่อนบางคนอาจถามว่าทำไมไม่สร้างความสามารถในการเรียก API ของ Web2 ลงในสภาพแวดล้อม VM บนเชนโดยตรง คำตอบคือไม่ เพราะเหตุผลที่จำเป็นต้องรักษาข้อมูลปิดไว้ในสภาพแวดล้อมแบบออนเชนก็เพื่อให้แน่ใจถึงความสามารถในการตรวจสอบย้อนกลับของข้อมูลทั้งหมด นั่นคือ ในกระบวนการฉันทามติ โหนดทั้งหมดจะมีตรรกะการประเมินแบบรวมศูนย์เพื่อความแม่นยำของข้อมูลบางอย่างหรือผลลัพธ์การดำเนินการบางอย่าง หรือตรรกะการตรวจสอบเชิงวัตถุประสงค์ สิ่งนี้ช่วยให้แน่ใจว่าในสภาพแวดล้อมที่ไม่น่าไว้วางใจโดยสิ้นเชิง โหนดที่มีความตั้งใจดีส่วนใหญ่สามารถพึ่งพาข้อมูลซ้ำซ้อนของตัวเองเพื่อกำหนดความถูกต้องของผลลัพธ์โดยตรง อย่างไรก็ตาม เนื่องมาจากข้อมูล Web2 ทำให้ยากที่จะสร้างตรรกะการประเมินที่เป็นหนึ่งเดียว เนื่องจากความล่าช้าของเครือข่ายบางประการ โหนดต่างๆ อาจได้รับผลลัพธ์ที่แตกต่างกันเมื่อเข้าถึงทรัพยากร Web2 HTTPS ซึ่งจะเพิ่มความยากลำบากในการบรรลุฉันทามติ โดยเฉพาะอย่างยิ่งสำหรับพื้นที่ข้อมูลความถี่สูงบางพื้นที่ นอกจากนี้ ปัญหาสำคัญอีกประการหนึ่งก็คือความปลอดภัยของโปรโตคอล TLS ซึ่งโปรโตคอล HTTPS ขึ้นอยู่ด้วยนั้นขึ้นอยู่กับตัวเลขสุ่มที่สร้างโดยไคลเอนต์ (Client Random) (สำหรับการสร้างคีย์) และพารามิเตอร์การแบ่งปันคีย์เพื่อให้เกิดการเจรจากับเซิร์ฟเวอร์สำหรับคีย์การเข้ารหัส อย่างไรก็ตาม เรารู้ดีว่าสภาพแวดล้อมบนเชนนั้นเปิดกว้างและโปร่งใส หากสัญญาอัจฉริยะรักษาตัวเลขสุ่มและพารามิเตอร์การแบ่งปันคีย์ ข้อมูลคีย์จะถูกเปิดเผย ส่งผลให้ความเป็นส่วนตัวของข้อมูลถูกละเมิด
จากนั้น zkTLS จะเลือกใช้แนวทางอื่น โดยมีแนวคิดที่จะแทนที่กลไกฉันทามติแบบเดิมที่ใช้ Oracle ซึ่งมีต้นทุนสูง เพื่อให้ข้อมูลพร้อมใช้งานได้ผ่านการป้องกันด้วยการเข้ารหัส คล้ายกับการเพิ่มประสิทธิภาพของ OP-Rollup โดย ZK-Rollup ใน L2 โดยเฉพาะอย่างยิ่ง ด้วยการนำการพิสูจน์ความรู้เป็นศูนย์ ZKP มาใช้ และการคำนวณและสร้างการพิสูจน์สำหรับทรัพยากรที่ได้รับจากโหนดรีเลย์นอกเชนที่ร้องขอ HTTPS บางอย่าง ข้อมูลการตรวจสอบใบรับรอง CA ที่เกี่ยวข้อง หลักฐานการกำหนดเวลา และการพิสูจน์ความสมบูรณ์ของข้อมูลโดยอิงจาก HMAC หรือ AEAD และการรักษาข้อมูลการตรวจสอบที่จำเป็นและอัลกอริทึมการตรวจสอบบนเชน สัญญาอัจฉริยะจะสามารถตรวจสอบความถูกต้อง ความมีประสิทธิภาพ และความน่าเชื่อถือของแหล่งข้อมูลได้โดยไม่เปิดเผยข้อมูลสำคัญ รายละเอียดอัลกอริทึมที่เฉพาะเจาะจงจะไม่ถูกกล่าวถึงที่นี่ และผู้ที่สนใจสามารถศึกษาในเชิงลึกได้ด้วยตนเอง
ประโยชน์ที่ยิ่งใหญ่ที่สุดของโซลูชันทางเทคนิคนี้คือช่วยลดต้นทุนในการทำให้ทรัพยากร Web2 HTTPS พร้อมใช้งานได้ สิ่งนี้กระตุ้นให้เกิดความต้องการใหม่ๆ จำนวนมาก โดยเฉพาะอย่างยิ่งในการลดการซื้อราคาแบบออนเชนของสินทรัพย์แบบหางยาว การใช้เว็บไซต์ที่มีอำนาจในโลกของ Web2 เพื่อดำเนินการ KYC แบบออนเชน และด้วยเหตุนี้จึงทำให้การออกแบบสถาปัตยกรรมทางเทคนิคของ DID และ Web3 Games เหมาะสมที่สุด แน่นอนว่า เราพบว่า zkTLS ยังมีผลกระทบต่อบริษัท Web3 ที่มีอยู่ โดยเฉพาะกับโครงการ Oracle ที่เป็นกระแสหลักในปัจจุบัน ดังนั้น เพื่อรับมือกับผลกระทบดังกล่าว ยักษ์ใหญ่ในอุตสาหกรรม เช่น Chainlink และ Pyth จึงติดตามผลการวิจัยในทิศทางที่เกี่ยวข้องอย่างแข็งขัน โดยพยายามรักษาตำแหน่งที่โดดเด่นในกระบวนการทำซ้ำทางเทคโนโลยี ในเวลาเดียวกัน ยังจะก่อให้เกิดรูปแบบธุรกิจใหม่ๆ เช่น การเปลี่ยนจากการเรียกเก็บเงินตามเวลาแบบเดิมเป็นการเรียกเก็บเงินตามการใช้งาน การคำนวณเป็นบริการ เป็นต้น แน่นอนว่า ความยากที่นี่ก็เหมือนกับโครงการ ZK ส่วนใหญ่ นั่นก็คือจะลดต้นทุนการประมวลผลและทำให้มีมูลค่าเชิงพาณิชย์ได้อย่างไร
โดยสรุป เมื่อออกแบบผลิตภัณฑ์ คุณยังสามารถให้ความสนใจกับการพัฒนา zkTLS และบูรณาการเทคโนโลยีนี้ในแง่มุมที่เหมาะสมได้ บางทีคุณอาจค้นพบแนวทางใหม่ๆ ในด้านนวัตกรรมทางธุรกิจและสถาปัตยกรรมทางเทคนิค
