ทุกวัน ผู้คนสร้างข้อมูลที่ละเอียดอ่อนสูงถึง 4.02 แสน TB เนื่องจากแต่ละคนไม่ค่อยเต็มใจแบ่งปันข้อมูลอย่างกว้างขวาง ความต้องการในการคำนวณข้อมูลที่เป็นส่วนตัวจึงเพิ่มมากขึ้นอย่างต่อเนื่อง โซลูชันเหล่านี้ส่วนใหญ่พึ่งพาโครงสร้างพื้นฐานของ Amazon Web Services (AWS) ซึ่งมีส่วนแบ่งตลาดคลาวด์คอมพิวติ้งทั่วโลกประมาณ 30%.
อย่างไรก็ตาม AWS มีข้อบกพร่องหลายประการ ซึ่งส่วนใหญ่เกิดจากสถาปัตยกรรมแบบรวมศูนย์ แม้ว่าจะมีการนำเสนอการคอมพิวเตอร์ที่ปลอดภัยขึ้นผ่าน AWS Nitro Enclaves แต่ยังคงเผชิญกับความท้าทายที่สำคัญในด้านการนำไปใช้ของนักพัฒนา และยังเป็นอุปสรรคที่ลึกซึ้งต่อความปลอดภัยของบล็อกเชนและแอปพลิเคชัน Web3.
บทความนี้จะวิเคราะห์สถานะของ AWS และแนะนำโซลูชันคลาวด์ TEE แบบกระจายอำนาจ ซึ่งไม่เพียงแต่แก้ไขข้อบกพร่องของ AWS แต่ยังเอาชนะข้อจำกัดของ TEE อื่น ๆ ที่มีอยู่ อย่างไรก็ตาม ก่อนหน้านี้ เราจำเป็นต้องสำรวจว่า AWS และผลิตภัณฑ์ Nitro Enclaves ของมันทำไมถึงได้รับความนิยมและส่วนแบ่งตลาดที่สูงขนาดนี้ และยังมีปัญหาอะไรที่อยู่เบื้องหลังความก้าวหน้าเหล่านี้.
AWS Nitro เทียบกับ TEE
ปัจจุบัน AWS เป็นแพลตฟอร์มการประมวลผลบนระบบคลาวด์ที่ได้รับความนิยมมากที่สุด โดยสรุป AWS เป็นโครงสร้างพื้นฐานระบบคลาวด์สําหรับความต้องการด้านการประมวลผลทั้งหมดของนักพัฒนา รวมถึงการประมวลผล พื้นที่จัดเก็บ และบริการฐานข้อมูล อย่างที่เราทราบกันดีว่า AWS มีส่วนแบ่งการตลาดประมาณ 30% ของโครงสร้างพื้นฐานระบบคลาวด์ ซึ่งเป็นเปอร์เซ็นต์ที่ค่อนข้างใหญ่ วิศวกรซอฟต์แวร์หรือนักพัฒนาเกือบ 48% ใช้ AWS ไม่ทางใดก็ทางหนึ่ง ดังนั้นจึงเป็นที่ต้องการสูง
ด้วยความต้องการและกลุ่มลูกค้าที่ขยายตัว รวมถึงสถาบันการเงินขนาดใหญ่ที่มีข้อมูลที่มีความละเอียดอ่อนสูง หน่วยงานของรัฐบาล และสตาร์ทอัพ ผู้คนได้ตั้งคำถามเกี่ยวกับความปลอดภัยของ AWS และความสามารถของหน่วยงานเหล่านี้ในการจัดเก็บและใช้ข้อมูลเหล่านี้อย่างปลอดภัยในการคำนวณที่เป็นความลับ.
ในบริบทนี้ AWS จึงเกิดแนวคิดในการนำ TEE มาประยุกต์ใช้บนแพลตฟอร์มของตนเพื่อปกป้องข้อมูลที่กำลังใช้งาน เพื่อเสริมการเข้ารหัสข้อมูลที่เป็นสถิติและข้อมูลที่อยู่ในระหว่างการส่ง
โซลูชันใหม่สําหรับการรวม TEE นี้เรียกว่า AWS Nitro Enclaves และมีสภาพแวดล้อมการดําเนินการแบบแยกส่วนที่รองรับฮาร์ดแวร์ TEEs สร้างสภาพแวดล้อมที่ปลอดภัยภายในอินสแตนซ์ Amazon EC2 ขจัดการเข้าถึงแบบโต้ตอบ พื้นที่จัดเก็บถาวร และการเชื่อมต่อเครือข่ายภายนอก การแยกนี้ช่วยลดพื้นผิวการโจมตีโดยการแยกปริมาณงานที่ละเอียดอ่อนออกจากอินสแตนซ์ EC2 หลัก ตัวดําเนินการ และซอฟต์แวร์อื่นๆ
!
อย่างไรก็ตาม Nitro Enclaves ถูกสร้างขึ้นและจัดการทั้งหมดภายในบริการ EC2 ของ AWS และเป็นเฟรมเวิร์กแบบรวมศูนย์สูง การจัดการทุกด้านของ Enclave จะถูกควบคุมโดยโครงสร้างพื้นฐานของ AWS ซึ่งรวมศูนย์โดยเนื้อแท้เนื่องจากลักษณะของ AWS ในฐานะผู้ให้บริการระบบคลาวด์แบบรวมศูนย์
กล่าวโดยย่อ AWS Nitro Enclaves ให้การแยกที่แข็งแกร่งผ่านสภาพแวดล้อมการดําเนินการที่เชื่อถือได้บนฮาร์ดแวร์เพื่อปกป้องปริมาณงานที่ละเอียดอ่อน อย่างไรก็ตามสถาปัตยกรรมแบบรวมศูนย์แนะนําข้อ จํากัด และการแลกเปลี่ยนบางอย่าง
ข้อจำกัดนอกเหนือจาก AWS ที่เป็นศูนย์กลาง
นอกจากข้อเสียของระบบศูนย์กลางที่ทุกองค์ประกอบและข้อมูลพึ่งพาอยู่ในระบบเดียวแล้ว AWS Nitro Enclaves ยังนำมาซึ่งความท้าทายและการพิจารณาด้านความปลอดภัยใหม่ ๆ อีกมากมาย AWS เชื่อมต่อการ์ด Nitro หลายใบ (ฮาร์ดแวร์ที่ปรับแต่ง) เข้ากับ CPU เพื่อรันโหลด TEE ซึ่งสร้างความเสี่ยงด้านความปลอดภัยสองเท่า: CPU ที่อยู่เบื้องหลังและการ์ด Nitro อาจมีช่องโหว่ได้
ปัญหาสําคัญของ Nitro Enclaves คือการขาดกลไกการเข้ารหัสหน่วยความจําที่เป็นที่ยอมรับ ซึ่งแตกต่างจากโซลูชันที่การเข้ารหัสหน่วยความจําถูกรวมเข้ากับ CPU โดยตรงลักษณะภายนอกของการ์ด Nitro ทําให้ยากต่อการเข้ารหัสข้อมูลในหน่วยความจําแบบ end-to-end การกําหนดค่านี้สามารถเปิดเผยข้อมูลที่ละเอียดอ่อนสําหรับการปลอมแปลงระหว่างการเข้าถึงหน่วยความจําเนื่องจากการเข้ารหัสขึ้นอยู่กับการโต้ตอบระหว่าง CPU และอุปกรณ์ภายนอก
นอกจากนี้ นักพัฒนายังคงต้องใช้ Docker เพื่อสร้างและกําหนดค่า Amazon Machine Images (AMI) ที่มีซอฟต์แวร์ Enclave ซึ่งอาจเป็นเรื่องยากสําหรับผู้ที่ไม่คุ้นเคยกับคอนเทนเนอร์ พวกเขายังต้องใช้ AWS CLI และ Nitro Enclaves CLI เพื่อเปิดใช้อินสแตนซ์และจัดการ Enclaves นําทาง Nitro Enclaves API และผสานรวมกับบริการการจัดการคีย์ของ AWS ซึ่งบางครั้งต้องมีความเข้าใจในกระบวนการรับรองการเข้ารหัส
การพึ่งพา Nitro Card ของ TEE ทำให้เกิดการพิสูจน์ที่ไม่สามารถตรวจสอบได้ เนื่องจากการวัดความสมบูรณ์ของโค้ดมาจาก Nitro Card ไม่ใช่ CPU เอง.
AWS เชื่อมั่นในนักพัฒนาและผู้ดูแลระบบในการตั้งค่านโยบายการจัดการตัวตนและการเข้าถึง ซึ่งอาจทำให้พวกเขาสามารถเข้าถึงข้อมูลที่ละเอียดอ่อนได้ สิทธิ์การเข้าถึงขั้นสูงของพวกเขาเกิดความเสี่ยงจากภัยคุกคามภายใน เนื่องจากพวกเขาอาจดูหรือแก้ไขข้อมูลได้
การตรวจสอบสมมติฐานความเชื่อมั่นของ AWS Nitro
อย่างไรก็ตาม ข้อจํากัดที่สําคัญที่สุดคือ AWS ไม่ได้รับการปรับให้เหมาะสมสําหรับแอปพลิเคชันและระบบนิเวศแบบกระจายอํานาจ และขาดการสนับสนุนแบบเนทีฟสําหรับกรณีการใช้งาน Web3 หรือระบบการกํากับดูแล
เช่น AWS Nitro Enclaves ขาดการจัดเก็บข้อมูลถาวร แม้ว่าการแยกนี้จะเป็นประโยชน์ต่อความปลอดภัย แต่ก็จำกัดกรณีการใช้งานเช่น AI ตัวแทนที่ต้องการจัดเก็บข้อมูลผู้ใช้ในฐานข้อมูลเวกเตอร์
การจัดการที่สําคัญยังไม่เหมาะกับสถานการณ์ “zero trust” แม้ว่า AWS Key Management Service (KMS) จะพร้อมใช้งาน แต่ได้รับการออกแบบมาสําหรับ Web2 และอนุญาตให้ผู้ดูแลระบบเข้าถึงคีย์ส่วนตัวได้ สิ่งนี้ขัดแย้งกับข้อกําหนดของ Web3 ที่ว่าคีย์จะต้องควบคุมโค้ดอย่างสมบูรณ์และไม่เปิดเผยต่อใครรวมถึงผู้ดูแลระบบ
Nitro Enclaves แก้ปัญหาความไม่ไว้วางใจของนักพัฒนาในระบบคลาวด์ แต่ Web3 ต้องการโซลูชันที่ไม่น่าเชื่อถือระหว่างผู้ใช้ นักพัฒนา และผู้ขาย ไม่รองรับการอัปเกรดรหัสที่ปลอดภัยต้องการความเป็นเจ้าของแบบกระจายอํานาจคล้ายกับการกํากับดูแลสัญญาอัจฉริยะและนักพัฒนาต้องสร้างตั้งแต่เริ่มต้นซึ่งอาจใช้เวลาหลายเดือนและหากไม่ดําเนินการอย่างถูกต้องรหัสอาจมีช่องโหว่
เนื่องจากขาดการเข้าถึงเครือข่าย การตั้งค่า Web service ใช้เวลานานและยากลำบาก ทำให้ผู้พัฒนาต้องเขียนโค้ดจำนวนมากเพื่อปรับให้เข้ากับแอปพลิเคชันและรับประกันความปลอดภัยของการเข้ารหัส ซึ่งมักจะไม่สมบูรณ์แบบ.
ทําไม Web3 ถึงต้องการ TEE?
เราใช้ TEE เนื่องจากเราไม่สามารถไว้วางใจนักพัฒนาหรือผู้ดูแลระบบได้อย่างเต็มที่ ผู้เข้าร่วม Web3 มีปรัชญาที่แตกต่างกันและติดตามระบบที่ไม่น่าเชื่อถือ: หากบางสิ่งต้องเชื่อถือได้ก็ดูไม่น่าเชื่อถือมากนัก นั่นเป็นเหตุผลที่ผู้ใช้พึ่งพาผู้ให้บริการฮาร์ดแวร์ในการตรวจสอบและจัดการแอปพลิเคชัน สามารถถอดแอปพลิเคชันออกเพื่อป้องกันไม่ให้รบกวนหรือขูดหรือเปลี่ยนแปลงข้อมูลที่ละเอียดอ่อนระหว่างการเข้าถึงหน่วยความจําเนื่องจากการเข้ารหัสอาศัยการทํางานร่วมกันที่ราบรื่นระหว่าง CPU และอุปกรณ์ภายนอก ผู้ใช้และผู้ให้บริการข้อมูลจําเป็นต้องมีการรับประกันที่ชัดเจนและการตรวจสอบการดําเนินการกับข้อมูลของตน
ในการพัฒนา Phala Network จุดมุ่งหมายของเราคือการรวมจุดแข็งของ AWS กับความปลอดภัยของ TEE โดยการลดความซับซ้อนผ่านการกระจายอำนาจ ในขณะเดียวกันก็เพิ่มความปลอดภัย วิธีการนี้มีเป้าหมายเพื่อตอบสนองความต้องการของกรณีการใช้งาน Web3 ผลลัพธ์คือเรานำเสนอแนวคิดของคลาวด์ TEE แบบกระจายอำนาจ เพื่อให้ความปลอดภัยและการบูรณาการสำหรับแอปพลิเคชันแบบกระจายอำนาจ
สร้างคลาวด์ TEE แบบกระจายอำนาจ
เพื่อที่จะเข้าใจแนวคิดของ TEE คลาวด์แบบกระจายอำนาจ ก่อนอื่นต้องกำหนดว่า คลาวด์แบบกระจายอำนาจคืออะไร แล้วมันคืออะไรล่ะ?
คลาวด์ที่ไร้ศูนย์กลางคือโครงสร้างพื้นฐานการประมวลผลที่การจัดเก็บข้อมูล การประมวลผล และการจัดการกระจายอยู่ในเครือข่ายของหลายโหนดแทนที่จะรวมอยู่ในเซิร์ฟเวอร์กลางหรือศูนย์ข้อมูลเดียว คลาวด์ที่ไร้ศูนย์กลางแตกต่างจากระบบคลาวด์แบบรวมศูนย์แบบดั้งเดิม เช่น AWS ตรงที่ไม่จำเป็นต้องมีหน่วยงานควบคุมเดียว แต่จะพึ่งพาเทคโนโลยีบล็อกเชนในการดำเนินงาน.
คลาวด์ TEE แบบกระจายศูนย์
คลาวด์ TEE แบบกระจายศูนย์เป็นโครงสร้างพื้นฐานการคำนวณที่รวม TEE เข้ากับเครือข่ายโหนดแบบกระจายศูนย์ เพื่อให้การคำนวณที่ปลอดภัย ส่วนตัว และสามารถตรวจสอบได้ ทุกโหนดจะมี TEE ติดตั้งอยู่เพื่อปกป้องโค้ดที่ละเอียดอ่อนและข้อมูลจากการเข้าถึงหรือการดัดแปลงของผู้ดำเนินการโหนด.
Phala Networkประกอบด้วยเครือข่ายโหนดการทำงานแบบกระจายศูนย์ ซึ่งแต่ละโหนดจะติดตั้ง TEE โหนดเหล่านี้ดำเนินการตามความต้องการของลูกค้าเพื่อทำงานคอมพิวเตอร์ให้กับผู้ใช้ เช่น การรันสมาร์ทคอนแทรคหรือการประมวลผลข้อมูลที่ละเอียดอ่อน.
กระบวนการเริ่มต้นด้วยผู้ใช้ปรับใช้แอปหรืองานของตนกับเครือข่าย งานคํานวณจะดําเนินการภายใน TEE ของโหนดเหล่านี้เพื่อให้แน่ใจว่ารหัสและข้อมูลยังคงเป็นความลับและแม้แต่ตัวดําเนินการโหนดก็ไม่สามารถดูหรือยุ่งเกี่ยวกับพวกเขาได้
!
Phala ใช้การพิสูจน์ทางการเข้ารหัสเพื่อยืนยันว่าการคำนวณภายใน TEE ได้ดำเนินการอย่างถูกต้อง ผู้ดำเนินการโหนดจะได้รับรางวัลจากการให้บริการที่ซื่อสัตย์และปลอดภัย โดยรักษาความสมบูรณ์ของเครือข่ายผ่านแรงจูงใจทางเศรษฐกิจ แม้ว่านี่จะฟังดูง่าย แต่การนำวิธีแก้ปัญหานี้ไปใช้จริงนั้นซับซ้อนกว่าที่เห็นมาก.
ทำไมการสร้างคลาวด์ TEE ที่กระจายอำนาจจึงเป็นเรื่องยากนัก?
TEE เองไม่ได้รวมศูนย์หรือกระจายอํานาจและระดับของการรวมศูนย์ขึ้นอยู่กับวิธีการใช้งานและปรับใช้ในระบบ TEE เป็นพื้นที่แยกที่ปลอดภัยภายในโปรเซสเซอร์ที่ออกแบบมาเพื่อปกป้องรหัสและข้อมูลที่ละเอียดอ่อนจากการเข้าถึงโดยไม่ได้รับอนุญาตโดยระบบปฏิบัติการหรือกระบวนการอื่น ๆ บนอุปกรณ์เดียวกัน ไม่ว่า TEE จะทํางานในโหมดรวมศูนย์หรือกระจายอํานาจหรือไม่นั้นขึ้นอยู่กับสถาปัตยกรรมของระบบที่กว้างขึ้นซึ่งตั้งอยู่
ในอดีตการสร้างระบบรวมศูนย์นั้นง่ายกว่าการสร้างระบบกระจายอํานาจซึ่งต้องเผชิญกับความท้าทายในแง่ของการใช้งานและการสื่อสารโหนด ก่อน Phala Cloud เราได้สร้าง Phala Network 1.0 (SGX) แบบกระจายอํานาจอย่างสมบูรณ์ Phala Cloud กําลังได้รับการพัฒนาด้วยปรัชญาเดียวกันแม้ว่าจะต้องใช้เวลา ปัจจุบัน Phala เป็นแพลตฟอร์มเดียวที่รวม TEE เข้ากับการกระจายอํานาจเต็มรูปแบบ ซึ่งแตกต่างจากผู้ให้บริการแบบรวมศูนย์หรือโปรโตคอลแบบกระจายอํานาจบางส่วน
ข้อดีของการกระจายอํานาจและ TEE นั้นชัดเจน แต่ก็ยังไม่เพียงพอในการพัฒนาผลิตภัณฑ์ ลองนึกภาพอาลีบาบาเป็นแพลตฟอร์มอีคอมเมิร์ซที่ใหญ่ที่สุดในโลกที่มีส่วนแบ่งการตลาดมหาศาล หากผลิตภัณฑ์ใหม่เปิดตัวด้วยพลังสองเท่าและราคาที่ต่ํากว่าจะเข้าครอบงําตลาดทั้งหมดหรือไม่? น่าเสียดายที่ไม่เพราะผู้คนคุ้นเคยกับผลิตภัณฑ์ที่มีอยู่และมีอคติต่อผลิตภัณฑ์ใหม่แม้ว่าจะดีกว่าก็ตาม
นี่เป็นหนึ่งในความท้าทายที่เราเผชิญ แต่แทนที่จะปรับปรุงเป็นสองเท่าเราตรวจสอบให้แน่ใจว่า Phala ซึ่งดีกว่าการแข่งขันสิบเท่านั้นใช้งานง่าย นอกจากนี้ ดังที่ได้กล่าวไว้ก่อนหน้านี้ AWS ไม่เหมาะสําหรับสภาพแวดล้อม Web3 และเรามุ่งมั่นที่จะเติมเต็มช่องว่างนี้สําหรับแอปพลิเคชัน Web3 และนักพัฒนา นอกจากข้อได้เปรียบที่ชัดเจนของการกระจายอํานาจแล้ว เรายังต้องการเน้นความแตกต่างอื่นๆ ระหว่าง Phala และ AWS อีกด้วย
Phala Cloud เทียบกับ AWS
ขั้นแรก AWS มีขั้นตอนการตั้งค่า Nitro Enclaves ที่ซับซ้อน ซึ่งเกี่ยวข้องกับหลายขั้นตอนรวมถึงการติดตั้ง Nitro CLI การแปลงภาพ Docker เป็นไฟล์ Enclave และการจัดการการถ่ายโอนไฟล์ ซึ่งทั้งหมดนี้ใช้เวลานานมาก
ในทางตรงกันข้าม Phala ช่วยให้นักพัฒนาสามารถปรับใช้ “ได้ทันที” และโยกย้ายคอนเทนเนอร์ Docker ที่มีอยู่ไปยัง TEE ที่ปลอดภัยได้อย่างง่ายดาย ด้วย Dstack SDK นักพัฒนาสามารถแปลงคอนเทนเนอร์ Docker เป็น VM ที่เป็นความลับโดยมีการเปลี่ยนแปลงเพียงเล็กน้อยและปรับใช้ผ่าน Cloud UI ที่ใช้งานง่ายในขณะที่ยังคงรองรับเทมเพลตและไฟล์ Docker Compose ที่กําหนดเอง
เมื่อพูดถึงความปลอดภัย AWS ต้องพึ่งพาความไว้วางใจให้นักพัฒนาและผู้ดูแลระบบกําหนดค่าการควบคุมการเข้าถึงและจัดการทรัพยากรอย่างเหมาะสม แม้ว่า AWS จะใช้ TEE สําหรับการประมวลผลแบบแยกส่วน แต่โครงสร้างพื้นฐานแบบรวมศูนย์ต้องการผู้ที่ไว้วางใจ AWS และจัดการระบบ ซึ่งอาจนําไปสู่การเข้าถึงข้อมูลที่ละเอียดอ่อนได้ Phala ใช้รูปแบบ zero-trust และไม่ไว้วางใจฝ่ายใดฝ่ายหนึ่งโดยค่าเริ่มต้น ข้อมูลที่ละเอียดอ่อนยังคงปลอดภัยภายใน TEE และไม่สามารถเข้าถึงได้แม้กระทั่งกับผู้ให้บริการโหนด ทําให้เหมาะสําหรับแอปพลิเคชัน Web3 ที่ต้องการการทํางานที่ไม่น่าเชื่อถือ
จากมุมมองของผลิตภัณฑ์ AWS ให้บริการลูกค้าองค์กรเป็นหลักเนื่องจากมีองค์กรจํานวนมากในพื้นที่ไอทีแบบดั้งเดิม ด้วยเหตุนี้จึงไม่สอดคล้องกับคุณค่าของสตาร์ทอัพ Web3 ในแง่ของผลิตภัณฑ์และเทคโนโลยี ในทางตรงกันข้าม Phala สร้างขึ้นตามวัตถุประสงค์สําหรับแอปพลิเคชันแบบกระจายอํานาจ รองรับพร็อกซี AI ที่โต้ตอบกับสัญญาอัจฉริยะของบล็อกเชน รวมถึง DApps ที่รักษาความเป็นส่วนตัว
นอกจากนี้ Phala ยังรวมเข้ากับระบบนิเวศบล็อกเชนอย่างลึกซึ้งผ่านการเป็นพันธมิตรกับโปรโตคอลต่างๆ และการผสานรวมกับ DApps ที่ต้องการใช้ประโยชน์จากความปลอดภัยของ TEE
Phala อยู่ในตําแหน่งชั้นการดําเนินการของ Web3 AI ทําให้นักพัฒนาสามารถสร้าง เปิดตัว และสร้างรายได้จากตัวแทน AI ที่สามารถเข้าใจและโต้ตอบกับสัญญาอัจฉริยะบล็อกเชนได้อย่างปลอดภัยและเป็นส่วนตัว เรารองรับแพลตฟอร์ม AI แบบกระจายอํานาจ เช่น NEAR AI และ Sentient โดยใช้ประโยชน์จาก NVIDIA GPU TEE เพื่อเรียกใช้โมเดลภาษาขนาดใหญ่ (LLMs) ในสภาพแวดล้อมที่ปลอดภัย ตรวจสอบได้ และเน้นความเป็นส่วนตัว ตัวอย่างเช่น ความร่วมมือของเรากับ NOTAI เน้นย้ําถึงการบังคับใช้ zero-trust ของตัวแทน AI ซึ่งเราให้การปกป้องแบบไร้ความน่าเชื่อถือและความเป็นส่วนตัวผ่าน TEE และ RA Explorer
เรายังสนับสนุนการรวมแอปพลิเคชันที่ไม่เกี่ยวข้องกับ AI ผ่าน Phat Contracts ซึ่งเป็นสมาร์ทคอนแทรกต์ที่มีต้นทุนต่ำและความหน่วงต่ำที่รองรับการร้องขอ HTTP แบบเนทีฟ
อย่างไรก็ตาม เนื่องจากทีมงานดั้งเดิมในวงการคริปโตหลายทีมกำลังพัฒนา TEE และวิธีการคำนวณที่ปลอดภัยอื่นๆ Phala จะทำให้แตกต่างจากโซลูชันเหล่านี้ได้อย่างไร?
Phala Cloud และ TEE โซลูชัน
Phala Network เป็นแพลตฟอร์มคลาวด์ที่ไม่เป็นศูนย์กลางที่โดดเด่นเพียงแห่งเดียวที่มี TEE โดยให้การคอมพิวเตอร์ที่ปลอดภัย ส่วนตัว และสามารถตรวจสอบได้สำหรับ DApp แตกต่างจาก Oasis Protocol และ Secret Network ซึ่งมุ่งเน้นไปที่การใช้ TEE เพื่อให้สัญญาอัจฉริยะที่เปิดใช้งานความเป็นส่วนตัวในบล็อกเชนของตนเอง ในขณะที่ Phala นำเสนอแพลตฟอร์มการคอมพิวเตอร์คลาวด์แบบกระจายที่สามารถคำนวณออฟไลน์ข้ามเครือข่ายได้.
Phala มีความยืดหยุ่นและปรับแต่งได้โดยใช้ประโยชน์จากฮาร์ดแวร์ TEE ที่หลากหลายรวมถึง Intel SGX, Intel TDX, AMD SEV และ NVIDIA GPU TEE Marlin Protocol เพิ่มประสิทธิภาพเครือข่ายของ Web3 แต่ไม่มีคุณสมบัติการคํานวณหรือความเป็นส่วนตัวในขณะที่ Oasis และ Secret ทํางานในระบบนิเวศบล็อกเชนเฉพาะ Phala อยู่ในตําแหน่งที่ไม่เหมือนใครในฐานะคลาวด์ TEE แบบกระจายอํานาจเพียงแห่งเดียวที่มีการสนับสนุนฮาร์ดแวร์ที่กว้างขวางและเครื่องมือที่เน้นนักพัฒนาเป็นศูนย์กลางเช่น Dstack
!
Phala นั้นแตกต่างกันตรงที่มีระบบคลาวด์ TEE แบบกระจายอํานาจทั่วไปซึ่งแตกต่างจาก Oasis Protocol, Marlin และ Secret Network ซึ่งมุ่งเน้นไปที่กรณีการใช้งานเฉพาะ Phala ช่วยให้นักพัฒนาสามารถปรับใช้แอปพลิเคชันใด ๆ เช่นโมเดล AI เว็บเซิร์ฟเวอร์หรือฐานข้อมูลในสภาพแวดล้อมที่ปลอดภัย สิ่งนี้เกิดขึ้นได้ผ่าน Phat Contracts และ Phala Cloud ซึ่งรองรับการปรับใช้ Dockerized และให้การเข้าถึง CPU และ GPU TEE ได้ในคลิกเดียว
นอกจากนี้ ยังมีการเปรียบเทียบว่า TEE หรือ การคำนวณหลายฝ่าย (MPC) อันไหนเหมาะสมกว่าสำหรับกรณีการใช้งานเฉพาะมากมาย ในมุมมองของเรา TEE และ MPC ไม่ใช่คู่แข่ง แต่เป็นพันธมิตรที่เสริมซึ่งกันและกัน.
Phala รวม TEE เข้ากับ MPC เพื่อสร้างโมเดล Root of Trust (DeRoT) แบบกระจายอํานาจ ซึ่งเป็นแนวทางขั้นสูงสําหรับการรักษาความปลอดภัยแอปพลิเคชันที่ใช้ TEE MPC ทํางานภายใน TEE เพื่อลดความเสี่ยงของการสมรู้ร่วมคิดของโหนดในขณะที่หลักฐานบล็อก TEE จะถูกส่งด้วยหลักฐาน MPC เพื่อลดข้อผิดพลาดในการใช้งาน zero-knowledge proofs (ZKP) ระบบการรับรองหลายรายการนี้ได้รับการปรับปรุงเพิ่มเติมโดยข้อกําหนดสําหรับโหนด MPC ในการทํางานภายใน TEE โมเดล DeRoT ใช้ TEE, MPC และ ZKP เพื่อกระจายความไว้วางใจในเครือข่าย วิธีนี้ช่วยเพิ่มความปลอดภัยของ DApps โดยใช้ TEEs โดยจัดการกับภัยคุกคามระดับฮาร์ดแวร์หรือโหนดที่อาจเกิดขึ้น
ความเป็นไปได้ของคลาวด์ TEE แบบกระจายศูนย์
เราจะอุทิศบทความให้กับหัวข้อนี้เนื่องจากมีแอปพลิเคชั่นมากมายที่ทํางานบน Phala ด้วยเหตุนี้ส่วนนี้อาจยาวเท่ากับบทความทั้งหมด แต่เราต้องการร่างกรณีการใช้งานที่เป็นไปได้สําหรับระบบคลาวด์ TEE แบบกระจายอํานาจ
ประการแรก Phala สนับสนุนการปรับใช้โมเดล AI ภายใน TEE เพื่อให้แน่ใจว่าการโต้ตอบกับเครือข่ายบล็อกเชนมีความปลอดภัยและเป็นอิสระ ซึ่งรวมถึงพร็อกซี AI สําหรับการปรับปรุงสัญญาอัจฉริยะและการโต้ตอบข้ามตัวแทน นักพัฒนาสามารถใช้ประโยชน์จาก GPU TEE สําหรับการประมวลผล AI เพื่อให้ได้ความต้านทานการเซ็นเซอร์ที่แท้จริงและการปกป้องความเป็นส่วนตัว
นักพัฒนายังสามารถโยกย้ายแอปพลิเคชันรุ่นเก่าไปยังสภาพแวดล้อมที่ปลอดภัยและเชื่อถือได้เพื่อปรับปรุงความปลอดภัย แพลตฟอร์มนี้ช่วยให้สามารถวิเคราะห์ข้อมูลแบบรักษาความเป็นส่วนตัวผ่าน Web3 และเครื่องมือวิเคราะห์แบบดั้งเดิมที่สามารถวิเคราะห์ข้อมูลได้โดยไม่ต้องเปิดเผยข้อมูลผู้ใช้แต่ละราย นอกจากนี้ยังสามารถปรับปรุงการคํานวณที่ปลอดภัยของ DeFi ด้วยคุณสมบัติความเป็นส่วนตัวเช่นตําแหน่งการซื้อขายที่เป็นความลับหรือการซื้อขายกลุ่มมืด สุดท้ายระบบคลาวด์ TEE แบบกระจายอํานาจสามารถใช้การป้องกัน MEV ได้โดยการย้ายบิลด์บล็อกไปยัง TEE เพื่อการสั่งซื้อและการดําเนินการที่เป็นธรรม
มีผลิตภัณฑ์มากมายที่ใช้ Phala เป็นส่วนหนึ่งของโครงสร้างพื้นฐาน เราจะเจาะลึกเกี่ยวกับผลิตภัณฑ์เหล่านี้ว่ามีการใช้ Phala อย่างไรและพวกเขาได้รับประโยชน์อะไรจากการรวมนี้ในบทความอื่น
สรุป
มีความแตกต่างพื้นฐานในโมเดลความน่าเชื่อถือของ Web3 และ Web2 ซึ่งนําไปสู่ข้อจํากัดสําหรับแพลตฟอร์มเช่น AWS ใน Web3 ข้อมูลรวมถึงโทเค็นที่เป็นข้อมูลเป็นหลักเป็นของผู้ใช้อย่างแท้จริงและนักพัฒนาแอปจะไม่ได้รับความไว้วางใจตามค่าเริ่มต้น ความไม่ไว้วางใจนี้เกิดจากศักยภาพของนักพัฒนาซอฟต์แวร์ที่จะพยายามเข้าถึงแก้ไขหรือขโมยข้อมูลผู้ใช้โดยไม่ได้รับอนุญาต
แนวทางนี้อธิบายถึงแนวปฏิบัติที่สำคัญหลายประการใน Web3:
- โค้ดสมาร์ทคอนแทรคต้องผ่านการตรวจสอบอย่างเข้มงวดเพื่อกำจัดช่องโหว่หรือประตูหลังออกไป
การเป็นเจ้าของ (หรือการควบคุมการจัดการ) ของสัญญาอัจฉริยะเป็นปัญหาที่สำคัญ ผู้ใช้ให้ความสำคัญกับความโปร่งใสมากกว่าการอนุญาตให้ผู้พัฒนามีอำนาจควบคุมที่ไม่มีข้อจำกัด
2.ในสถานการณ์ที่เหมาะสม นักพัฒนาควรเขียนและปรับใช้โค้ดสัญญาอัจฉริยะในสภาพแวดล้อม Web3 จากนั้นควรละทิ้งอำนาจควบคุมทั้งหมด ไม่ควรรักษาสิทธิพิเศษใด ๆ ต่อแอปพลิเคชันอีกต่อไป.
ซึ่งแตกต่างจากสัญญาอัจฉริยะ TEEs สามารถบังคับใช้หลักการที่คล้ายกันของการเป็นเจ้าของและการควบคุมภายในช่วงกว้างของขั้นตอน อย่างไรก็ตาม AWS Nitro Enclaves ทํางานภายในเฟรมเวิร์ก Web2 ซึ่งนักพัฒนายังคงสามารถเข้าสู่ระบบ เข้าถึง และแก้ไขข้อมูลและแอปพลิเคชันได้ TEE ของ Phala ได้รับการออกแบบตามหลักการ Web3 และรองรับสัญญาอัจฉริยะเพื่อจัดการแอปพลิเคชันที่ใช้ TEE ซึ่งสอดคล้องกับรูปแบบความไว้วางใจแบบกระจายอํานาจ
