Minggu lalu, saya terus terjebak pada sebuah pertanyaan kecil tentang pembuktian (proof) dalam kripto.
Sebelum bertanya apakah proof bisa diverifikasi, bagaimana cara mengetahui bahwa itu masih merupakan proof awal yang benar?
Beberapa hari kemudian, setelah membaca bagian contoh zkTLS Twitter/X di dokumentasi Newton Protocol, saya berhenti pada detail proofCid.
Awalnya, saya pikir CID hanya semacam alamat untuk menyimpan proof.
Sebuah proof zkTLS dibuat. Client menyimpan proof tersebut. Gateway mengembalikan proofCid. Setelah itu, task menggunakan CID ini agar operator tahu proof mana yang harus diambil saat menjalankan evaluasi policy.
Sekilas terlihat seperti langkah penyimpanan file yang cukup normal.
Tapi semakin saya baca dengan saksama, saya semakin merasa @NewtonProtocol bukan sekadar menanyakan proof itu ada di mana.
Ini sedang menanyakan apakah konten di balik alamat itu benar proof yang telah dibuat oleh client.
Itulah titik yang membuat CID berbeda dari URL biasa.
URL biasanya mengatakan di mana konten itu bisa ditemukan.
CID menyatakan sesuatu yang lebih kuat: seperti apa hash untuk konten ini.
Kalau kontennya berubah, CID juga harus berubah. Jadi, proofCid bukan hanya penunjuk (pointer). Ia adalah komitmen terhadap bytes yang ada di balik pointer tersebut.
Namun dalam alur authorization, hanya menerima satu CID dari Gateway lalu langsung percaya itu saja masih belum cukup.
Contoh Newton tidak berhenti hanya pada penerimaan proofCid. Saat mengambil (retrieve) bytes proof, client memverifikasi bahwa bytes yang dikembalikan cocok dengan multihash dari CID. Setelah store(), SDK juga menurunkan (re-derive) CID dari bytes yang telah dikirim sendiri dan menolak jika respons Gateway tidak cocok.
Detail ini kecil, tetapi membuka batas yang sangat penting.
Newton tidak membiarkan proofCid menjadi sebuah janji dari Gateway.
Dia menepati janji itu lalu kembali mencocokkan dengan bytes yang benar.
Karena itu, client tidak menyerahkan sepenuhnya rasa percaya ke Gateway atau lapisan storage ketika evidence dimasukkan ke jalur authorization. Ia memeriksa ulang—bukan dengan perasaan percaya, melainkan dengan mencocokkan CID dengan konten itu sendiri.
Bagian ini yang menurut saya menarik.
Sebuah zkTLS proof bisa benar. Sebuah policy bisa ditulis dengan benar. Sebuah task bisa terlihat sah. Tapi jika pemindahan (handoff) antara pembuatan proof dan evaluasi policy meleset—jika proofCid mengarah ke bytes yang berbeda dari proof awal—maka sistem sedang mengevaluasi evidence yang salah.
Kesalahan saat itu bukan terletak pada kriptografi proof.
Itu ada di batas penyimpanan (storage) evidence.
Protocol Newton tampaknya berusaha mencegah kesalahan itu sejak batas client. Sebelum proof dimasukkan ke dalam task, sebelum para operator menggunakannya, sebelum policy bergantung padanya, client harus memastikan bahwa alamat dan konten yang sebenarnya benar-benar cocok.
Dilihat dari sudut pandang itu, CID Integrity Boundary bukan soal menyimpan proof demi kenyamanan.
Itu adalah cara menjaga agar evidence tidak disabotase/diubah dalam perjalanan dari saat dibuat sampai digunakan untuk mengotorisasi (authorize).
Tentu saja, integritas CID tidak menyelesaikan semuanya.
Itu tidak membuktikan bahwa claim di dalam proof itu baik. Ia tidak menggantikan policy. Ia juga tidak memastikan bahwa sumber data eksternal selalu dapat dipercaya.
Tapi ia melindungi satu bagian yang sangat spesifik: proof disimpan, diambil kembali, dan dimasukkan ke dalam task tanpa mengubah konten yang berada di balik alamat tersebut.
Bagi saya, ini detail kecil tapi patut diperhatikan dalam Newton.
Authorization tidak hanya perlu aturan yang benar.
Belum perlu evidence yang benar.
Dan sebelum evidence dipercaya, sistem harus memastikan bahwa evidence itu benar-benar merupakan sesuatu yang dibuat oleh user/client.
Mungkin proofCid sebaiknya tidak dianggap sebagai tautan (link) ke proof.
Janji itu seharusnya dianggap bahwa proof di balik tautan tersebut belum dipalsukan atau diganti.