Penulis: @Web3_Mario
Ringkasan: Belakangan ini saya mencari arah proyek baru dan menemukan teknologi stack yang sebelumnya tidak saya kenal saat mendesain produk, sehingga saya melakukan riset dan merangkum pembelajaran saya untuk dibagikan kepada semua. Secara keseluruhan, zkTLS adalah teknologi baru yang menggabungkan bukti nol pengetahuan (ZKP) dan TLS (protokol keamanan transportasi), yang terutama digunakan dalam lingkungan mesin virtual di Web3 untuk memverifikasi keaslian data HTTPS off-chain yang disediakan tanpa harus mempercayai pihak ketiga. Keaslian ini mencakup tiga aspek: sumber data benar-benar berasal dari sumber HTTPS tertentu, data yang dikembalikan tidak dimodifikasi, dan keefektifan data dapat dijamin. Melalui mekanisme implementasi kriptografi ini, kontrak pintar di blockchain dapat memperoleh kemampuan akses tepercaya ke sumber daya Web2 HTTPS off-chain, memecahkan masalah pulau data.
Apa itu protokol TLS
Untuk memahami nilai teknologi zkTLS secara mendalam, perlu untuk memberikan ringkasan singkat tentang protokol TLS. Pertama, TLS (protokol keamanan transport layer) digunakan untuk menyediakan enkripsi, otentikasi, dan integritas data dalam komunikasi jaringan, memastikan transmisi data yang aman antara klien (seperti browser) dan server (seperti situs web). Teman-teman yang tidak berada di jalur pengembangan jaringan mungkin akan menemukan bahwa saat mengakses situs web, beberapa nama domain memiliki awalan https, sementara yang lainnya memiliki awalan http. Dan saat mengakses yang terakhir, browser utama akan memberikan peringatan tidak aman. Sedangkan yang pertama sering kali menghadapi peringatan “Tautan Anda bukan tautan pribadi” atau kesalahan sertifikat HTTPS. Alasan dari peringatan ini adalah terkait dengan ketersediaan protokol TLS.
Secara spesifik, protokol HTTPS adalah protokol yang menjamin privasi dan integritas transmisi informasi di atas protokol HTTP dengan memanfaatkan protokol TLS, dan memastikan bahwa keaslian server dapat diverifikasi. Kita tahu bahwa protokol HTTP adalah protokol jaringan yang mentransfer data dalam bentuk plaintext dan tidak dapat memverifikasi keaslian server, yang menyebabkan beberapa masalah keamanan:
1. Informasi yang Anda kirimkan ke server dapat didengarkan oleh pihak ketiga, yang dapat menyebabkan kebocoran privasi;
2. Anda tidak dapat memverifikasi keaslian server, yaitu apakah permintaan Anda telah disusupi oleh node jahat lainnya dan mengembalikan informasi jahat;
3. Anda tidak dapat memverifikasi integritas informasi yang dikembalikan, yaitu apakah mungkin ada kehilangan data karena alasan jaringan;
Sementara itu, protokol TLS dirancang untuk menyelesaikan masalah ini. Di sini perlu dijelaskan bahwa beberapa teman mungkin mengetahui protokol SSL, sebenarnya protokol TLS dikembangkan berdasarkan versi SSL 3.1, hanya saja karena beberapa masalah terkait bisnis, namanya diubah, tetapi sebenarnya merupakan kelanjutan yang sama. Oleh karena itu, dalam beberapa konteks, kedua istilah tersebut dapat dipertukarkan.
Sementara itu, pemikiran utama dari protokol TLS untuk menyelesaikan masalah di atas adalah:
1. Komunikasi terenkripsi: menggunakan kriptografi simetris (AES, ChaCha20) untuk melindungi data, mencegah penyadapan.
2. Otentikasi identitas: memverifikasi identitas server melalui sertifikat digital yang diterbitkan oleh pihak ketiga untuk institusi tertentu (seperti sertifikat X.509), mencegah serangan man-in-the-middle (MITM).
3. Integritas data: menggunakan HMAC (kode otentikasi pesan hash) atau AEAD (enkripsi otentikasi) untuk memastikan data tidak dimodifikasi.
Mari kita jelaskan dengan sederhana tentang detail teknis protokol HTTPS berbasis protokol TLS dalam proses interaksi data, keseluruhan proses dibagi menjadi dua tahap, pertama adalah tahap handshake, yaitu klien dan server bernegosiasi parameter keamanan dan membangun sesi terenkripsi. Selanjutnya adalah tahap pengiriman data, yaitu menggunakan kunci sesi untuk komunikasi terenkripsi. Proses spesifik dibagi menjadi empat langkah:
1. Klien mengirim ClientHello:
Klien (seperti browser) mengirim pesan ClientHello ke server, yang mencakup:
Versi TLS yang didukung (seperti TLS 1.3)
Algoritma kriptografi yang didukung (Cipher Suites, seperti AES-GCM, ChaCha20)
Angka acak (Client Random) (digunakan untuk generasi kunci)
Parameter berbagi kunci (seperti kunci publik ECDHE)
SNI (indikator nama server) (opsional, untuk mendukung HTTPS multi-domain)
Tujuannya adalah untuk memberi tahu server tentang kemampuan kriptografi klien dan mempersiapkan parameter keamanan.
2. Server mengirim ServerHello:
Server merespons pesan ServerHello, yang mencakup:
Algoritma kriptografi yang dipilih
Angka acak server (Server Random)
Sertifikat server (sertifikat X.509)
Parameter berbagi kunci server (seperti kunci publik ECDHE)
Selesai 消息（digunakan untuk mengonfirmasi penyelesaian handshake）
Tujuannya adalah untuk memberi tahu klien tentang identitas server dan mengonfirmasi parameter keamanan.
3. Klien memverifikasi server:
Klien melakukan operasi berikut:
Verifikasi sertifikat server: memastikan sertifikat diterbitkan oleh CA yang tepercaya (otoritas sertifikat), sambil memverifikasi apakah sertifikat telah kedaluwarsa atau dicabut;
Menghitung kunci bersama: menggunakan kunci publik ECDHE dari klien dan server untuk menghitung kunci sesi, yang digunakan untuk kriptografi simetris dalam komunikasi selanjutnya (seperti AES-GCM).
Mengirim pesan Finished: membuktikan integritas data handshake, mencegah serangan man-in-the-middle (MITM).
Tujuannya adalah untuk memastikan server dapat dipercaya dan menghasilkan kunci sesi.
4. Mulai komunikasi terenkripsi:
Klien dan server sekarang menggunakan kunci sesi yang telah dinegosiasikan untuk komunikasi terenkripsi.
Menggunakan kriptografi simetris (seperti AES-GCM, ChaCha20) untuk mengenkripsi data, meningkatkan kecepatan dan keamanan.
Perlindungan integritas data: menggunakan AEAD (seperti AES-GCM) untuk mencegah penyimpangan.
Jadi setelah empat langkah ini, masalah protokol HTTP dapat diselesaikan secara efektif. Namun, teknologi dasar yang secara luas diterapkan dalam jaringan Web2 ini telah menyebabkan kesulitan dalam pengembangan aplikasi Web3, terutama ketika kontrak pintar di blockchain ingin mengakses data off-chain tertentu, karena masalah ketersediaan data, mesin virtual di blockchain tidak akan membuka kemampuan pemanggilan data eksternal untuk memastikan semua data dapat dilacak, sehingga menjamin keamanan mekanisme konsensus.
Namun setelah serangkaian iterasi, pengembang menemukan bahwa DApp masih membutuhkan data off-chain, sehingga muncul serangkaian proyek Oracle, seperti Chainlink dan Pyth. Mereka bertindak sebagai jembatan relay antara data di blockchain dan data off-chain untuk memecahkan fenomena pulau data. Selain itu, untuk memastikan ketersediaan data relay, Oracle ini umumnya menggunakan mekanisme konsensus PoS, yaitu membuat biaya berbuat salah bagi node relay lebih tinggi daripada manfaatnya, sehingga dari segi keuntungan ekonomi mereka tidak akan memberikan informasi yang salah ke blockchain. Misalnya, jika kita ingin mengakses harga BTC yang terweighted di bursa terpusat seperti Binance dan Coinbase dalam kontrak pintar, kita perlu mengandalkan Oracle ini untuk mengakses dan mengumpulkan data di luar blockchain sebelum disimpan dalam kontrak pintar di blockchain.
Apa yang diselesaikan oleh zkTLS
Namun orang-orang menemukan bahwa solusi pengambilan data berbasis Oracle ini memiliki dua masalah:
1. Biaya terlalu tinggi: Kita tahu bahwa untuk memastikan data yang disampaikan oleh Oracle ke blockchain adalah data yang nyata dan tidak dimodifikasi, perlu dijamin oleh mekanisme konsensus PoS, namun keamanan mekanisme konsensus PoS dibangun di atas jumlah dana yang dipertaruhkan, yang membawa biaya pemeliharaan. Selain itu, dalam banyak kasus, terdapat banyak redundansi interaksi data dalam mekanisme konsensus PoS, karena ketika kumpulan data perlu ditransfer, dihitung, dan dirangkum secara berulang di jaringan untuk mencapai konsensus, ini juga meningkatkan biaya penggunaan data. Oleh karena itu, biasanya proyek Oracle hanya akan gratis untuk memelihara beberapa data paling mainstream, seperti harga aset utama seperti BTC. Sedangkan untuk kebutuhan khusus, perlu membayar. Ini menghalangi inovasi aplikasi, terutama untuk beberapa kebutuhan khusus dan tail-end.
2. Efisiensi yang terlalu rendah: dalam banyak kasus, konsensus mekanisme PoS memerlukan waktu tertentu, yang menyebabkan keterlambatan data di blockchain, yang tidak menguntungkan untuk beberapa skenario akses frekuensi tinggi, karena data yang diperoleh di blockchain memiliki keterlambatan yang cukup besar dibandingkan data asli off-chain.
Untuk mengatasi masalah di atas, teknologi zkTLS lahir. Pemikiran utamanya adalah dengan memperkenalkan algoritma bukti nol pengetahuan (ZKP), memungkinkan kontrak pintar di blockchain bertindak sebagai pihak ketiga yang dapat secara langsung memverifikasi data yang disediakan oleh suatu node, bahwa data tersebut memang diambil dari sumber HTTPS tertentu dan tidak dimodifikasi, sehingga dapat menghindari biaya penggunaan yang tinggi akibat algoritma konsensus tradisional.
Beberapa teman mungkin bertanya, mengapa tidak langsung memberikan kemampuan panggilan API Web2 di lingkungan VM di blockchain. Jawabannya adalah tidak bisa, karena lingkungan di blockchain perlu menjaga data tertutup untuk memastikan semua data dapat dilacak, yaitu selama proses konsensus, semua node memiliki logika penilaian yang seragam terhadap keakuratan data atau hasil eksekusi tertentu, atau bisa disebut sebagai logika verifikasi yang objektif. Ini memastikan bahwa dalam lingkungan yang sepenuhnya tidak mempercayai, sebagian besar node yang baik dapat bergantung pada data redundan mereka untuk menentukan kebenaran hasil langsung. Namun, karena data Web2, sangat sulit untuk membangun logika penilaian yang seragam, karena mungkin karena beberapa alasan keterlambatan jaringan, hasil yang diperoleh oleh node yang berbeda saat mengakses sumber daya HTTPS Web2 mungkin berbeda, yang menambah kesulitan dalam konsensus, terutama untuk beberapa bidang data frekuensi tinggi. Selain itu, masalah kunci lainnya adalah keamanan protokol TLS yang bergantung pada angka acak yang dihasilkan oleh klien (Client Random) (digunakan untuk generasi kunci) dan parameter berbagi kunci, untuk melakukan negosiasi kunci enkripsi dengan server, tetapi kita tahu bahwa lingkungan di blockchain bersifat terbuka dan transparan. Jika kontrak pintar harus mempertahankan angka acak dan parameter berbagi kunci, maka data kunci akan terekspos, yang akan merusak privasi data.
Nah, zkTLS menggunakan cara lain, yaitu, melalui perlindungan kriptografi, menggantikan biaya tinggi yang dibawa oleh mekanisme konsensus tradisional untuk mendapatkan ketersediaan data. Mirip dengan optimasi ZK-Rollup terhadap OP-Rollup di L2. Secara spesifik, dengan memperkenalkan pembuktian nol pengetahuan (ZKP), dan meminta node relay off-chain untuk sumber daya tertentu dari HTTPS, terkait informasi verifikasi sertifikat CA, bukti waktu, serta bukti integritas data berbasis HMAC atau AEAD, untuk dihitung menjadi Proof, dan mempertahankan informasi verifikasi serta algoritma verifikasi yang diperlukan di blockchain, sehingga kontrak pintar dapat memverifikasi keaslian, keefektifan, dan keandalan sumber data tanpa mengekspos informasi kunci. Detail algoritma spesifik tidak dibahas di sini, teman-teman yang tertarik bisa melakukan penelitian lebih lanjut.
Keuntungan terbesar dari solusi teknologi ini adalah menurunkan biaya ketersediaan sumber daya HTTPS Web2. Ini telah memicu banyak permintaan baru, terutama dalam menurunkan harga pengambilan aset tail-end di blockchain, menggunakan situs web otoritatif di dunia Web2 untuk melakukan KYC di blockchain, sehingga mengoptimalkan desain arsitektur teknologi DID dan Web3 Game, dll. Tentu saja, kita dapat melihat bahwa zkTLS juga memberikan dampak pada perusahaan Web3 yang ada, terutama untuk proyek Oracle yang saat ini umum. Oleh karena itu, untuk menghadapi dampak ini, raksasa industri seperti Chainlink, Pyth, dll. aktif mengikuti penelitian terkait arah ini, berusaha untuk tetap memegang posisi dominan dalam proses iterasi teknologi, dan juga akan memunculkan model bisnis baru, seperti peralihan dari biaya berdasarkan waktu ke biaya berdasarkan penggunaan, Compute as a service, dll. Tentu saja, tantangannya seperti kebanyakan proyek ZK lainnya adalah bagaimana menurunkan biaya komputasi sehingga memiliki nilai komersial.
Kesimpulannya, teman-teman dapat memperhatikan perkembangan teknologi zkTLS saat merancang produk dan mengintegrasikan stack teknologi ini di aspek yang tepat, mungkin dapat menemukan arah baru dalam inovasi bisnis dan desain arsitektur teknologi.